Don't abuse private fields get/set by reflection
Using reflection as that is done in several answers here is something that we could avoid.
It brings a small value here while it presents multiple drawbacks :
- we detect reflection issues only at runtime (ex: fields not existing any longer)
- We want encapsulation but not a opaque class that hides dependencies that should be visible and make the class more opaque and less testable.
- it encourages bad design. Today you declare a
@Value String field. Tomorrow you can declare 5 or 10 of them in that class and you may not even be straight aware that you decrease the design of the class. With a more visible approach to set these fields (such as constructor) , you will think twice before adding all these fields and you will probably encapsulate them into another class and use @ConfigurationProperties.
Make your class testable both unitary and in integration
To be able to write both plain unit tests (that is without a running spring container) and integration tests for your Spring component class, you have to make this class usable with or without Spring.
Running a container in an unit test when it is not required is a bad practice that slows down local builds : you don't want that.
I added this answer because no answer here seems to show this distinction and so they rely on a running container systematically.
So I think that you should move this property defined as an internal of the class :
@Component
public class Foo{
@Value("${property.value}") private String property;
//...
}
into a constructor parameter that will be injected by Spring :
@Component
public class Foo{
private String property;
public Foo(@Value("${property.value}") String property){
this.property = property;
}
//...
}
Unit test example
You can instantiate Foo without Spring and inject any value for property thanks to the constructor :
public class FooTest{
Foo foo = new Foo("dummyValue");
@Test
public void doThat(){
...
}
}
Integration test example
You can injecting the property in the context with Spring Boot in this simple way thanks to the properties attribute of @SpringBootTest :
@SpringBootTest(properties="property.value=dummyValue")
public class FooTest{
@Autowired
Foo foo;
@Test
public void doThat(){
...
}
}
You could use as alternative @TestPropertySource but it adds an additional annotation :
@SpringBootTest
@TestPropertySource(properties="property.value=dummyValue")
public class FooTest{ ...}
With Spring (without Spring Boot), it should be a little more complicated but as I didn't use Spring without Spring Boot from a long time I don't prefer say a stupid thing.
As a side note : if you have many @Value fields to set, extracting them into a class annotated with @ConfigurationProperties is more relevant because we don't want a constructor with too many arguments.
