- if you have code with a lot of mocks, then we regard that as a design smell. The test is telling you to break up the object into something simpler. With more smaller objects, I find I'm less likely to break the world when the design changes.
- if I only have "real" objects, how do I break dependencies when I'm unit testing? Do I write some minimal implementations? In which case, I might as well use a framework and we're back to square one.
- unit tests are not (just) about regression, they're also about guiding us to cleaner designs. If I rip out my unit tests after the system passes, I lose that feedback when I need to change the working code.
What I see frequently enough in practice is complaints about the maintainability of bad code tested with mocks. If the structure is weak, then mocks are not my biggest problem. That's not to say never delete existing tests, but not to throw them all out either.
So what I'm hearing is that if your code is well designed, the tests likely are still useful when you come to change that design. So you don't automatically throw unit tests away when the guiding test passes.
I also think it's worth examining your second point in more detail. How do you break dependencies when unit testing, without using mocks? That sounds like a topic for another post.
4 comments:
I think there a couple of questions here.
- if you have code with a lot of mocks, then we regard that as a design smell. The test is telling you to break up the object into something simpler. With more smaller objects, I find I'm less likely to break the world when the design changes.
- if I only have "real" objects, how do I break dependencies when I'm unit testing? Do I write some minimal implementations? In which case, I might as well use a framework and we're back to square one.
- unit tests are not (just) about regression, they're also about guiding us to cleaner designs. If I rip out my unit tests after the system passes, I lose that feedback when I need to change the working code.
What I see frequently enough in practice is complaints about the maintainability of bad code tested with mocks. If the structure is weak, then mocks are not my biggest problem. That's not to say never delete existing tests, but not to throw them all out either.
So what I'm hearing is that if your code is well designed, the tests likely are still useful when you come to change that design. So you don't automatically throw unit tests away when the guiding test passes.
I also think it's worth examining your second point in more detail. How do you break dependencies when unit testing, without using mocks? That sounds like a topic for another post.
So what about cooking?
What is, according to you, the same?
Michel - there are lots of similarities. Surely you can work it out for yourself.
Post a Comment