concept test in category spring

After running the command in a terminal, you’ll be asked for a password and details about your “certificate authority”. Because it is only a self-signed certificate for a test, you can input any data here, just make sure to remember the password. The command outputs two files: key.pem, which is the private key cert.pem, which is a public certificate. We’ll use these further to generate our self-signed certificate to use for enabling HTTPS. In most of the cases, the certificate is a Public Key Cryptography Standard #12 (PKCS12). Less frequently, we use a Java Key Store (JKS) format. Let’s continue our example with a PKCS12 format. For an excellent discussion on cryptography, I also recommend “Real-World Cryptography” by David Wong (Manning, 2020).

20.1  Using mock users for test

In this section, we discuss using mock users to test the authorization configuration. This approach is the most straightforward but also the most used for testing authorization configurations. When using a mock user, the test completely skips the authentication (figure 20.3). The mock user is valid only for the test execution, and you can configure for this user any characteristics you need to validate a specific scenario. You could, for example, give specific roles to the user, ADMIN or MANAGER, or different authorities to validate that the app behaves as expected in these conditions.

Figure 20.3 The components shaded differently from the Spring Security authentication flow are skipped when executing a test. The test directly uses a mock SecurityContext, which contains the mock user you define to call the tested functionality.

In the test folder of the Spring Boot maven project, we’ll add a class named MainTests. I’ll write this class as part of the main package of the application. In my case, the name of the main package is com.laurentiuspilca.ssia. In listing 20.1, you find the definition of the empty class for the tests. We use the @SpringBootTest annotation, which represents a convenient way to manage the Spring context for our tests suite.

Listing 20.1 A class for writing the tests

@SpringBootTest    #A
public class MainTests {
 
}

#A Making Spring Boot responsible for managing the Spring context for the tests.

A convenient way to implement a test for the behavior of an endpoint is using MockMvc. In a Spring Boot application, MockMvc utility for testing endpoint calls can be autoconfigured only by adding an annotation over the class as presented in listing 20.2.

With all this setup complete, we can write a test to use the custom way we’ve defined for building the SecurityContext.

Listing 20.11 Writing a test that uses the custom SecurityContext

@SpringBootTest
@AutoConfigureMockMvc
public class MainTests {
 
  @Autowired
  private MockMvc mvc;
 
  @Test
  @WithCustomUser(username = "mary")    #A
  public void helloAuthenticated() throws Exception {
    mvc.perform(get("/hello"))
         .andExpect(status().isOk());
  }
}

#A Executing the test with a user having the username “mary”

Running the test, you’ll observe a successful result. You might think, “Wait! In this example, we implemented a custom AuthenticationProvider, which only authenticates a user john. How could the test be successful with the username mary?”. Like in the case of @WithMockUser and @WithUserDetails, with this method, we skip the authentication logic. So you could use it only to test what’s related to authorization and onwards.

The Initializr also gave you a skeleton test class to help you get started with writing tests for your application. But ReadingListApplicationTests (listing 2.2) is more than just a placeholder for tests—it also serves as an example of how to write tests for Spring Boot applications.

Listing 2.2. @SpringApplicationConfiguration loads a Spring application context

In a typical Spring integration test, you’d annotate the test class with @ContextConfiguration to specify how the test should load the Spring application context. But in order to take full advantage of Spring Boot magic, the @SpringApplicationConfiguration annotation should be used instead. As you can see from listing 2.2, ReadingListApplicationTests is annotated with @SpringApplicationConfiguration to load the Spring application context from the ReadingListApplication configuration class.

ReadingListApplicationTests also includes one simple test method, contextLoads(). It’s so simple, in fact, that it’s an empty method. But it’s sufficient for the purpose of verifying that the application context loads without any problems. If the configuration defined in ReadingListApplication is good, the test will pass. If there are any problems, the test will fail.

5.3. Running tests with the CLI

Tests are an important part of any software project, and they aren’t overlooked by the Spring Boot CLI. Because CLI-based applications don’t involve a traditional build system, the CLI offers a test command for running tests.

Before you can try out the test command, you need to write a test. Tests can reside anywhere in the project, but I recommend keeping them separate from the main components of the project by putting them in a subdirectory. You can name the subdirectory anything you want, but I chose to name it “tests”:

$ mkdir tests

Within the tests directory, create a new Groovy script named ReadingListControllerTest.groovy and write a test for the ReadingListController. To get started, listing 5.3 has a single test method for testing that the controller handles HTTP GET requests properly.

Standard dependency injection allows you to reduce coupling by addressing unambiguous type coupling. One way to do this is to move the instantiation concern into a single configuration file rather than code. Removing the code that instantiates the collaborators for your services both reduces coupling and simplifies the code. This makes maintenance easier, simplifies testing by allowing tests to inject test-only implementations, and increases the chances of reuse. The following example shows the new version of the BookingService, which now exposes a constructor that accepts instances of its collaborators:

Listing 5.1. Running a test using @Test

package siia.business; import org.junit.Test; import org.junit.runner.RunWith; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.integration.Message; import org.springframework.integration.MessageChannel; import org.springframework.integration.core.PollableChannel; import org.springframework.integration.support.MessageBuilder; import org.springframework.test.context.ContextConfiguration; import org.springframework.test.context.junit4.SpringJUnit4ClassRunner; import java.util.Date; import static org.junit.Assert.assertEquals; import static org.junit.Assert.assertNotNull; @ContextConfiguration @RunWith(SpringJUnit4ClassRunner.class) public class FlightDelayTransformerIntegrationTests { @Autowired private MessageChannel flightDelayInput; @Autowired private PollableChannel delayEvents; @Test public void verifyDelay() { long currentTime = System.currentTimeMillis(); Message<String> message = MessageBuilder.withPayload("SI77+0130").build(); flightDelayInput.send(message); Message<?> transformed = delayEvents.receive(0); assertNotNull(transformed); Object payload = transformed.getPayload(); assertNotNull(payload); assertEquals(FlightDelayEvent.class, payload.getClass()); Date estimatedDeparture = ((FlightDelayEvent) payload).getEstimatedDeparture(); long secondsFor1hr30min = 90 * 60; long delay = estimatedDeparture.getTime() - currentTime; assertEquals(secondsFor1hr30min, delay / 1000); } }

There are many ways to test software. One of the oldest ways is to test it manually. Manual testing is still valid and in wide use because of its simplicity, but experienced developers dread the tedious work of so-called monkey testing. A lot of this work can be automated. Even better, if you can isolate a part of the program in such a way that it doesn’t require every test fixture to simulate human interaction, writing tests becomes a simple development task with excellent return on investment. SUnit, invented by some of the bright minds that also started the Agile movement, was ported to Java in the late 1990s. If you don’t know JUnit yet, firmly pull the handbrake toward you and make sure you learn JUnit before you read any further.

Figure 18.1. The test sends a message on the tripCommands channel and receives the subcommands that were sent by the splitter. Now a test can verify that the splitter is configured correctly by asserting that the payload of the messages matches the contents of the original TripCommand.

The timeout is also important. When designing a test case, you must understand that the main function of the test is to fail when the software doesn’t behave correctly. This main function is best implemented when the failure clearly points out what part of the behavior was incorrect. If the receive call had no timeout, and an exception were thrown from the service, the test could run indefinitely. The test wouldn’t fail in this case of malfunctioning in the software under test, so the test would be flawed. You could put a general timeout on the test to prevent it from running indefinitely. The timeout would fix the flaw, but the failure message would have no relation to the cause of the failure. The test would be correct but not very useful.

Finally, the assertions should be in the right order. If the service isn’t invoked, you’ll most likely get no output message. In this case, mixing the order of the assertions will make the test fail with an “Output didn’t arrive” message, or worse, a Null-PointerException. Thinking carefully about the order of the assertions can prevent this problem.

test—This command configures JUnit tests both inside and outside of the Spring container. dod will configure data-on-demand objects, which are used by the integration tests to generate fake test data. We cover testing the persistence tier in chapters 3 and 4 and devote a full chapter to unit and web testing in chapter 9.

Now you’ve seen how you can write tests against live Spring beans such as Roo services and repositories. You can use this technique to test any Spring bean in your container; just autowire the bean into the test and exercise it as you would in your application code, using asserts to verify behavior.

Now that we’ve discussed how to write integration tests, we should mention that all of the tests introduced so far are rather invasive, looking at the system from the inside. Testers call these white-box tests.

Equally valuable are tests that look at the system as a black box: tests external to the application that exercise the application as a user would. For those tests, we’ll look at Roo’s support for web testing, using the Selenium automated web testing tool.

The test opens an entity creation page, types data on the page, and submits the form. You can go a step farther and assert that the data submitted by the test is reflected in the new page. Here’s a variation on the test that checks that the fields are shown in the show view, which is displayed after you submit. Copy your test-tag.jspx test to a test-tag-with-assertions.tagx, and add the lines in the following example to the end of the table:

<tr>
  <td>verifyText</td>
  <td>//div[@id='_s_org_rooina_coursemanager_model_Tag_tag_tag_id']</td>
  <td>someTag1</td>
</tr>
<tr>
  <td>verifyText</td>
  <td>//div[@id='_s_org_rooina_coursemanager_model_Tag    _description_description_id']</td>
  <td>someDescription1</td>
</tr>

These commands verify that the div with the id specified in @id hold the value in the third table element. You can use the assertText command to fail the test and stop running further commands, but the verifyText command you’re using marks the test as failed while it continues to run the rest of the commands in the test file.

Let’s write a test that exercises a bean that processes student registrations. The bean provides a registerStudents method that accepts a set of students and an offering, and then registers students for the provided course offering.

Batch applications are like any other applications: you should test them using a framework like JUnit. Testing makes maintenance easier and detects regressions after refactoring. Let’s test, then! This section covers how to write an integration test for a Spring Batch job. You’ll also learn about the launching API in Spring Batch. But don’t be too impatient—we need a couple of intermediary steps before writing the test: configuring a test infrastructure and showing you a trick to make the job configuration more flexible.

1.6.3. Writing the test for the job

You use good old JUnit to write the test, with some help from the Spring testing support. The following listing shows the integration test for the job.

The test uses the Spring TestContext Framework, which creates a Spring application context during the test and lets you inject some Spring beans into the test (with the @Autowired annotation). The @RunWith and @ContextConfiguration trigger the Spring TestContext Framework. Chapter 14 is all about testing, so give it a read if you want to learn more about this topic. At , you clean and populate the database. This creates a consistent database environment for each @Test method. At , you launch the job with its parameters and check at that the job correctly inserted the products from the test ZIP archive. The test ZIP archive doesn’t have to contain thousands of records: it can be small so the test runs quickly.

You can now run the test with your favorite IDE (Eclipse, IDEA) or build tool (Maven, Ant). Figure 1.10 shows the result of the test execution in Eclipse.

Figure 1.10. Launching the test in Eclipse. Despite all its features, Spring Batch remains lightweight, making jobs easy to test.

The DynamicImport-Package header can contain a list of packages, but it also supports two wildcards for specifying package names. Moreover, these imports are searched for in the order in which they are specified. This ordering is important, especially when using wildcards, because it determines the order in which matching occurs. In the following snippet, packages with the value test for the attribute myat-tribute will be preferred over other packages.

We’ll stick to Maven 2’s project layout by putting tests in the src/test/java directory of our project. The project now has the following structure (with the test directory and its content shown in bold):

springdm-sample
  lib/
    (...)
  src/
    main/
      java/
        com/manning/springdmia/
          SpringDmSample.java
      resources/
        META-INF/
          spring/
        springdm-sample.xml
test/
java/
com/manning/springdmia/
SpringDmSampleTest.java
  build.bnd
  build.xml
  ivy.xml
  ivysettings.xml

Listing C.10 shows the backbone of our integration test. The test mainly consists of checking that our bundle has been installed and correctly started.

Listing C.10. The bundle integration test

The test will be updated in section C.4.2 to reflect that we don’t rely on the Maven 2 local repository to provision the OSGi container that the test framework bootstraps. For now, we just need to compile the test. Listing C.11 shows the updates needed in the build file to compile the test.

Listing C.11. Compiling the test with Ant

Modifications start at , with the declaration of properties for the location of test source files and for the test output directory. We take advantage of our dependencies at , by defining a dedicated path for our classpath. Note that the test compilation target depends on the resolve target , which means that the dependencies will be retrieved before its execution. We refer at to the classpath we created, as the test uses the OSGi API and the Equinox JAR (in the dependencies) provides this.

The test is almost ready to run, but before we do that, we need to tune the Spring DM test framework a little to use the Ivy-managed dependencies.

Listing 1.6. Test sets up a mock instance for EmailClient using Emailer’s Factory

Code that is modular is also easy to test. Testing specific modules (or components) is a vital part of their development, as it is the primary way to verify their correctness. Tests that rely on components to have dependencies wired are poor tests because they can easily confuse the issue when an error occurs. You may spend hours tracking down whether the component under test is responsible or if one of its dependencies caused the error. The use of mock objects is a powerful remedy to this predicament, and indeed it’s an important way to narrow down and verify the behavioral correctness of a piece of code. Never allow injectors or other environment-specific frameworks to creep into unit tests, even as a crutch. Try to use mocks and test units in isolation as much as possible. Code that conforms to this focus is said to be tested out of container.

So far we’ve shown how to test individual units and assert their behavior. This ought to be the first step in any development process. We’ve also lain down reasons for keeping tests independent of an injector or other environment-specific concerns. As your code matures, and the time arrives for a completed module to be integrated into the larger system, new testing concerns arise. These concerns have to do with the interoperation of modules, their dependence on external factors like hardware or database resources, and the overall coherence of the system. Automated tests can help in this regard too, and this flavor of tests is called integration tests.