5 ms·
> ... micro level unit testing, driven by people like Uncle Bob. "The structure of your tests should not be a mirror of the structure of your code. The fact th
by Ace17 9y ago
> ... micro level unit testing, driven by people like Uncle Bob.
"The structure of your tests should not be a mirror of the structure of your code. The fact that you have a class named X should not automatically imply that you have a test class named XTest."
"The structure of the tests must not reflect the structure of the production code, because that much coupling makes the system fragile and obstructs refactoring. Rather, the structure of the tests must be independently designed so as to minimize the coupling to the production code."
http://blog.cleancoder.com/uncle-bob/2017/10/03/TestContravariance.html http://blog.cleancoder.com/uncle-bob/2017/10/03/TestContrava...
- ancarda 9y agoI really wish Uncle Bob would provide code examples with his blog posts and videos. I struggle to imagine what my tests would look like if I followed this. Possibly as my tests are so tightly coupled right now that refactoring is actually not possible in some cases. Does anyone know of explations of this with a more hands-on approach, or is this simply a collection of ideas that can’t really be shown?
- hdi 9y agoI've been wondering about that for a while. So far, I've not been able to find any examples of test architecture that follows those principles online or in my day job. I've also been too lazy to do a side project and explore a more decoupled and scalable test suite. Maybe I should get off my arse and finally do it.
- twic 9y agoIf you're writing a web application, i've had a reasonably happy time with tests at the controller level, or perhaps right below. You want an interface where values go in and out that correspond to fairly user-level ideas, but which are still tractable for testing.
- ed_blackburn 9y agoPractical advice? Consider making every type internal. Then open them up to what is strictly required to be public. Now you are testing the behaviour of your application through its public surface. This reduces the brittleness of your tests because you can change the internal implementation without rewriting your tests. You have higher assurance. It'll also force your hand to enforce invariants and place guard clauses in the right places rather than "everywhere". If you follow Cockburn's Ports and Adapters approach too, then you can substitute adapters like persistent state, buses, HTTP clients for appropriate in-memory equivalents.
- spion 9y agoI think my example captures the spirit of this: https://news.ycombinator.com/item?id=16049441 https://news.ycombinator.com/item?id=16049441
- crdoconnor 9y ago>Then, clearly, if a small change to the production code causes large changes to the tests, there is a design problem. > >Therefore the tests must have their own design. They cannot simply follow along with the structure of the production code. The jump indicated by the "therefore" confuses me. I essentially couple my test to production behavior, insofar as it is possible. I do this to test program behavior realistically and because I believe tests should, in some sense, form a specification for the program they test. I don't really care about "testing code"; I care about testing behavior. I don't have the problem of small changes to code necessitating large changes to tests. It makes me wonder what he does that is causing that.
- vog 9y agoI agree that these types of tests are very good and usefuly, but: Don't they use the wrong term for them? I believe these tests are more commonly called "integration tests", not "unit tests". Or, did I misunderstand something?
- wst_ 9y agoIntegration tests are testing multiple modules and the way how they cooperate. These are mora a feature tests. Take a module as your unit, mock externals, give it an input and check the output/outcome.