Hello!
The comments on this profile are unclaimed and thus are unverified.
Do they belong to you? Claim these comments.
Thomas Kjeldahl Nilsson
Is this you? Claim Profile »
2 weeks ago
in Unit testing tricks: Look ma, no setters! on Thinking inside a bigger box
Two small additional points:
- I'd also be a little thrown off if I was reading the domain object code and seeing a bunch of fields set to protected instead of private for no apparent reason. Yes, tests are supposed to function as documentation but I don't always start reading unknown code from that direction.
- Position of arguments in the factory methods wouldn't be an issue if the desired object state was passed as a single struct / DTO instead. Of course, at this point you start to accumulate some noticeable infrastructure in the domain logic just to support tests, but I'd still prefer one/few factory objects over a lot of ad hoc object initialization all over the test cases. Again, personal preference. :)
- I'd also be a little thrown off if I was reading the domain object code and seeing a bunch of fields set to protected instead of private for no apparent reason. Yes, tests are supposed to function as documentation but I don't always start reading unknown code from that direction.
- Position of arguments in the factory methods wouldn't be an issue if the desired object state was passed as a single struct / DTO instead. Of course, at this point you start to accumulate some noticeable infrastructure in the domain logic just to support tests, but I'd still prefer one/few factory objects over a lot of ad hoc object initialization all over the test cases. Again, personal preference. :)
1 reply
2 weeks ago
in Unit testing tricks: Look ma, no setters! on Thinking inside a bigger box
Neat solution!
However, I think (and this is just a personal preference) that encurring the resulting WTF moment for all subsequent maintainers of the code can be a steep price to pay just to be able to set a bunch of methods protected instead of public. I guess it depends how much of a OO purist you are vs what sort of people are going to maintain that code.
Related question: would you be violently opposed to adding a function Account.getTestAccountInstance([state representation]) and set the domain object state for tests in that way? Not elegant, adds ugly non-domain-logic to the domain objects API but more readable and less WTF factor - at least to my eyes.
However, I think (and this is just a personal preference) that encurring the resulting WTF moment for all subsequent maintainers of the code can be a steep price to pay just to be able to set a bunch of methods protected instead of public. I guess it depends how much of a OO purist you are vs what sort of people are going to maintain that code.
Related question: would you be violently opposed to adding a function Account.getTestAccountInstance([state representation]) and set the domain object state for tests in that way? Not elegant, adds ugly non-domain-logic to the domain objects API but more readable and less WTF factor - at least to my eyes.
1 reply
jhannes
This is indeed a tricky tradeoff. (However, I don't think I'd set the *fields* public to support tests!)
We use Account.createAccountWithBalance() for similar cases. But when we found that each test needed to setup about 5 of 10 possible fields (different 5 for different tests), factory methods started to become confusing as well.
The tradeoff between a complex factory method and this trick is that the {{}}-trick is harder to understand the first time, but it's usually easier to read when a number of fields are being initialized (as opposed to remembering the position of each factory method argument).
Then there's the inner builder pattern....
We use Account.createAccountWithBalance() for similar cases. But when we found that each test needed to setup about 5 of 10 possible fields (different 5 for different tests), factory methods started to become confusing as well.
The tradeoff between a complex factory method and this trick is that the {{}}-trick is harder to understand the first time, but it's usually easier to read when a number of fields are being initialized (as opposed to remembering the position of each factory method argument).
Then there's the inner builder pattern....
When the problem starts to scale, I might consider builders, structs, introducing setters or something else. But it seems like a lot of extra code to write for the size of the problem.
There's a lot of tools in the "object initialization in test" toolbox. I'm still not thrilled with any of them.