How You Test = How You Design
I've recently started reading through all the design related posts at mockobjects.com.
They are highly recommended and I agree with all of the theory behind them and a lot of the practices. However what interested me most was that despite this I don't design software in the same way as them.
Take the "Test Smell: I need to mock an object I can't replace (without magic)" post as an example. I love the design exercise that the author goes through, and extracting the Clock/SameDayChecker class is superb. Yet something about it made me realize that I don't design the way they do and amn't sure I want to...
Refactoring v Need To Mock
In the example the design improvement is driven by the need to replace the time in a test.
Now I can understand the need to replace the time but I would also say that if your the sort of designer than looks at the original code and sees that its not cohesive enough then your going to extract the SameDayChecker concept regardless.
Maybe I'm wrong though, would I have looked at the original code and thought "good enough". Possibly, and if there was no pain then that might have been fine. So the tests have perhaps forced us to a better design.
However that leaves me a little cold as if we didn't need to replace the time for testing, or if the incohesive code had nothing to do with an external dependency, then we'd have settled for the first option.
If we thus use this style of testing to drive our designs then we only get good designs if we make every piece of the code replacable...
Injection
I dunno but to me the whole IoC thing is heavily influenced by Robert Martins ideas of dependency inversion.
Thing is I don't think Robert Martin meant that every class should be replacable, or at least I never read it that way.
I also don't think it should be used as your primary design technique, as in I want to test Customer without CustomerMustHaveAddressRule so i'll extract the rule (good) then inject it into Customer (huh). Do I really need to inject my rules into the domain, if I do then fine but for many line of business applications this would be overkill.
My approach would be extract the rule (SRP/cohesion etc.) but then use it directly from the domain. I'm unlikely to replace one rule with another implementation.
Why It Matters
I actually think using interaction testing as a design technique is interesting but when I look at the Clock/SameDayChecker example I'm left a little unhappy.
Am I really going to ever replace the SameDayChecker in production, is it really a meaningful dependency that I want my domain class to show. To me the answer is "probably not" to both.
I also think that IoC and injection of dependencies is great. However I definitely do not think everything needs to be injected when it comes to domain models, and if you use the design technique described then I think that you could end up with decoupling that I wouldn't find useful.
Lots of decoupling, much of which does nothing but make the design more complex without ever being taken advantage of, is my worry with some of these techniques.
No comments:
Post a Comment