Spring configuration information can be externalized from the main Java code, partitioned across one or more Java configuration files. In this step you’ll create a single configuration file that tells Spring how to configure your application components.

Under the src/main/java folder, find the config package and open the class RewardsConfig. Note that the class does not need to extend any other classes or implement any interfaces.

We will however add some code and Spring annotations to it to create the result illustrated in the RewardsConfig box below:

First, place a @Configuration annotation on the RewardsConfig class. This tells Spring to treat this class as a set of configuration instructions to be used when the application is starting up.

Next, within this RewardsConfig.java class, define four methods annotated with the @Bean annotation. Each method should instantiate and return one of the beans in the illustration, accountRepository, restaurantRepository, rewardRepository, and rewardNetwork. For example, you should create an accountRepository() method that instantiates JdbcAccountRepository and returns it.

Looking back at the illustration, you can see that each of the three repositories has a dependency on a DataSource that will be defined elsewhere. This means in each repository method we must make a call to the repository’s setDataSource(), passing in a reference to the dataSource. But where will we get the DataSource from when it is defined in another file (in our case in TestInfrastructureConfig.java)?

The class already has a DataSource defined for you, but we need to give it a value. To make the class easy to test, define a constructor that accepts a DataSource and sets dataSource.

Finally, you should be aware that Spring will assign each bean an ID based on the @Bean method name. The instructions below will assume that the ID for the RewardNetwork bean is rewardNetwork. Therefore, for consistency with the rest of the lab, give your RewardNetworkImpl @Bean method the name rewardNetwork.

For best practices, a bean’s name should describe the service it provides. It should not describe implementation details. For this reason, a bean’s name often corresponds to its interface. For example, the class JdbcAccountRepository implements the AccountRepository interface. This interface is what callers work with. By convention, then, the bean name should be accountRepository.

Similarly each bean method should return an interface not a concrete class. So the accountRepository() method should return AccountRepository not JdbcAccountRepository.

As RewardsConfig is a Java class we can unit test it. Once you have the four beans defined and referenced as shown in the configuration diagram, open RewardsConfigTests - in the config package under src/test/java.

Note that a mock dataSource has been defined already.

Uncomment the code between /* and */. This should compile if you implemented RewardsConfig correctly. If not, fix RewardsConfig as necessary. Make sure your @Bean methods have the right names, return the right implementations and that their signatures define interfaces as return types.

Run the test (in STS, right click anywhere in the code window, select Run As …​ then JUnit Test).

Once the test passes, move on to the next step!

In the previous step you visualized bean definitions for your application components. In this step we’ll investigate the infrastructure configuration necessary to test your application.

To test your application, each JDBC-based repository needs a DataSource to work. For example, the JdbcRestaurantRepository needs a DataSource to load Restaurant objects by their merchant numbers from rows in the T_RESTAURANT table. So far, though, you have not defined any DataSource implementation. In this step you’ll see how to setup a DataSource in a separate configuration file in your test tree. It’s in the test area, because it is only for testing - it is not the one you would use in production.

In the src/test/java source folder, navigate to the root rewards package. There you will find a file named TestInfrastructureConfig.java. Open it.

You will see that a DataSource is already configured for you. You don’t need to make any changes to this bean, but you do need to understand what we have defined here for you. This TestInfrastructureConfig.java will also serve as the master configuration class for our upcoming test. To have it serve in this role, add an @Import to the class to reference the RewardsConfig.class.

Spring ships with decent support for creating a DataSource based on in-memory databases such as H2, HSQLDB and Derby. The code you see is a quick way to create such a database.

Notice how the Builder references external files that contain SQL statements. These SQL scripts will be executed when the application starts. Both scripts are on the classpath, so you can use Spring’s resource loading mechanism and prefix both of the paths with classpath:. Note that the scripts will be run in the order specified (top to bottom) so the order matters in this case.

Start by creating a new JUnit Test Case called RewardNetworkTests in the rewards package inside the src/test/java source folder.

Once you have your RewardNetworkTests class created, move on to the next step!

In this step you’ll implement the setup logic needed to run your system test. You’ll first create a Spring ApplicationContext that bootstraps your application, then lookup the bean you’ll use to invoke the application.

First, notice that you have a public void setUp() method annotated with @org.junit.jupiter.api.BeforeEach - this was done for you when you selected the setUp() checkbox in JUnit test case wizard. @BeforeEach is the JUnit 5 equivalent of JUnit 4’s @Before.

Within setUp() call SpringApplication.run, providing it the TestInfrastructureConfig.class that you want to load. Doing this will bootstrap your application by having Spring create, configure, and assemble all beans defined in the two configuration files (since one imports the other).

Next, ask the context to get the rewardNetwork bean for you, which represents the entry-point into the rewards application. Assign the bean to a private field of type RewardNetwork you can reference from your test methods.

Don’t ask the context for beans "internal" to the application. The RewardNetwork is the application’s entry-point, setting the boundary for the application defined by an easy-to-use public interface. Asking the context for an internal bean such as a repository or data source is questionable.

Now verify that Spring can successfully create your application on test setup. To do this, modify the test() method:

Then, run your test class by selecting it and accessing Run >> Run As >> JUnit Test from the menu bar (you may also do this by right-clicking in the code window and using the Run As option in the popup menu). After your test runs, you should see the green bar indicating setUp() ran without throwing any exceptions.

If you see red, inspect the failure trace in the JUnit view to see what went wrong in the setup logic. Carefully inspect the stack trace - Spring error messages are usually very detailed in describing what went wrong. The most useful information is usually at the bottom of the stack trace, so you my need to scroll down to see it.

Once you have the green bar, move on to the last step!

Now the test setup logic works we can modify our test to invoke the RewardNetwork.rewardAccountFor(Dining) method and verify that all the pieces of your application work together to carry out a successful reward operation.

You will not have to write the Unit Test yourself. Have a look at RewardNetworkImplTest.testRewardForDining(). You can just copy and paste its content into RewardNetworkTests.testRewardForDining().

You can now rerun your test. In STS, you may simply select the green play button on the tool bar to Run Last Launched (CTRL+F11 or COMMAND+F11 on MacOS). A green play button can also be found in the JUnit view tab.

When you have the green bar, congratulations! You’ve completed this lab.

You have just used Spring to configure the components of a realistic Java application and have exercised application behavior successfully in a test environment inside your IDE.