CODEWITHSUNDEEP
javaspringspring-bootjunit
Phate
Phate

Reputation: 6612

Is it possible to test the properties injection correctness via JUNIT?

I have developed my application and I have a .properties file containing several key-value properties. In my code I inject said properties like this:

@Value("${services.host}${services.name}")
private String hostname;

I am searching for a way to check every @Value inside of my code so to make sure that every property will be solved at runtime. Something like simulating my application startup.

Is it possible?

Upvotes: 1

Views: 442

Answers (1)

Brad
Brad

Reputation: 15879

Yes, you can create a JUnit test class that loads your application context (just like your production code would) and then execute a test method that verifies that your property values have been injected.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = {AppConfig.class})
public class SpringApplicationTest {
    @Autowired
    private MyServiceBean serviceBean;

    @Test
    public void shouldExecuteServiceBean_andProduceExpectedOutcome() {
        //TODO test setup

        serviceBean.doSomething()

        //TODO assert output
    }
}

In this example MyServiceBean.java is a class that would be executed from your Main class, so that you are testing the end-to-end logic of your application, including all of the spring dependency injections. Think of it as your "happy path" test scenario. I always include at least one test like this in my projects, to ensure that all of the spring injections are correct and load without error. You wan't to catch the errors before you build and deploy your code.

In the example above AppConfig.java is the same Spring configuration class you use when your code is deployed. You probably want to add another configuration class that overrides some properties/beans specifically for testing only.

@ContextConfiguration(classes = {AppConfig.class, TestConfig.class})

Using a test only class, you can mock out any dependencies that make testing difficult (i.e. use an in-memory database), and also override properties so you can test against "localhost" rather than another service which may or may not be available (so long as you can create an equivalent localhost service in your test setup).

Note: If you are finding it difficult to test your application due to too many dependencies, or external dependencies that cannot be swapped out easily, the pain you are feeling is a good guide to start thinking about how to change your architecture to support ease of testing. You also can just test portions of your application using the above concepts.

Upvotes: 1

Related Questions