3 ms·

I disagree. Constructor injection in Spring is more test-friendly; in turn that tends to allow us the liberty of more aggressively modularising the design. Wit

I disagree. Constructor injection in Spring is more test-friendly; in turn that tends to allow us the liberty of more aggressively modularising the design. With other injection types either more bookkeeping is required to cleanly set up tests; or alternatively, "unit" testing becomes more integration-esque. It's a second-order effect felt in the many small decisions that lead one to the mudpit. That's why I used the analogy of dark matter. It's not directly observed, but it has gravity.

twic 10y ago
> Constructor injection in Spring is more test-friendly If you get in the habit of using the Spring test support, where classes under test get injected, then all kinds of injection are equally friendly, and the tests don't give you feedback on the weight of the dependencies because Spring does the heavy lifting. And, in my experience, where you do inject dependencies by hand, the design pressure is actually towards coarser-grained objects. Why? Because you need to have enough functionality to test; with fine-grained objects, you have to construct and assemble an object graph in the test, whereas with coarse-grained objects, you just new up one thing.
- EdwardDiego 10y ago
  > If you get in the habit of using the Spring test support, where classes under test get injected, then all kinds of injection are equally friendly, and the tests don't give you feedback on the weight of the dependencies because Spring does the heavy lifting. How do you handle the Spring context start-up time? In Spring projects I've worked on, across hundreds of unit tests it's non-trivial. But I don't make any claim to know if we were doing Spring right or not.
  - jacques_chester 10y ago
    If you're firm on constructor injection, you can typically test the object in complete isolation without necessarily using mocks, without Spring having to be involved. Or you can use mocks and Spring Boot's test annotations. But with field/setter injection, that choice isn't as easy.
  - twic 10y ago
    The context can be reused between tests. If you're not storing data in beans (which you normally shouldn't), this works well. There is a bit of subtlety in that the framework might have to create multiple context for different configurations, but each of them is reusable. Running a single test is a bit of pain, but running the whole suite is not a lot slower than if it didn't use Spring.
EdwardDiego 10y ago
> Constructor injection in Spring is more test-friendly These are my thoughts too. No reflection or @MoreAnnotations to inject dependencies. I have an aversion to setter/field based injection because it allows you to instantiate an object in an incorrect state.
- jacques_chester 10y ago
  > I have an aversion to setter/field based injection because it allows you to instantiate an object in an incorrect state. Oh yes. I recognise that JavaBeans had its reasons for being, but then you get to JPA and it's time for all the boggling.
  - lazulicurio 10y ago
    My personal pet peeve is bean validation. The goals of the API are laudable, but the fact that the implementation is annotation-driven drives me nuts. Annotations are fine for intra-project code contracts, but using them for external validation means that if you, say, deploy on a application server with an older version of Jersey, you're suddenly SOL when none of your validation logic is executed.

twic 10y ago

> Constructor injection in Spring is more test-friendly If you get in the habit of using the Spring test support, where classes under test get injected, then all kinds of injection are equally friendly, and the tests don't give you feedback on the weight of the dependencies because Spring does the heavy lifting. And, in my experience, where you do inject dependencies by hand, the design pressure is actually towards coarser-grained objects. Why? Because you need to have enough functionality to test; with fine-grained objects, you have to construct and assemble an object graph in the test, whereas with coarse-grained objects, you just new up one thing.

EdwardDiego 10y ago
> If you get in the habit of using the Spring test support, where classes under test get injected, then all kinds of injection are equally friendly, and the tests don't give you feedback on the weight of the dependencies because Spring does the heavy lifting. How do you handle the Spring context start-up time? In Spring projects I've worked on, across hundreds of unit tests it's non-trivial. But I don't make any claim to know if we were doing Spring right or not.
- jacques_chester 10y ago
  If you're firm on constructor injection, you can typically test the object in complete isolation without necessarily using mocks, without Spring having to be involved. Or you can use mocks and Spring Boot's test annotations. But with field/setter injection, that choice isn't as easy.
- twic 10y ago
  The context can be reused between tests. If you're not storing data in beans (which you normally shouldn't), this works well. There is a bit of subtlety in that the framework might have to create multiple context for different configurations, but each of them is reusable. Running a single test is a bit of pain, but running the whole suite is not a lot slower than if it didn't use Spring.

EdwardDiego 10y ago

> Constructor injection in Spring is more test-friendly These are my thoughts too. No reflection or @MoreAnnotations to inject dependencies. I have an aversion to setter/field based injection because it allows you to instantiate an object in an incorrect state.

jacques_chester 10y ago
> I have an aversion to setter/field based injection because it allows you to instantiate an object in an incorrect state. Oh yes. I recognise that JavaBeans had its reasons for being, but then you get to JPA and it's time for all the boggling.
- lazulicurio 10y ago
  My personal pet peeve is bean validation. The goals of the API are laudable, but the fact that the implementation is annotation-driven drives me nuts. Annotations are fine for intra-project code contracts, but using them for external validation means that if you, say, deploy on a application server with an older version of Jersey, you're suddenly SOL when none of your validation logic is executed.