3 ms·
I have to say that the trade-off argument brought up between DRY and readability is pretty lame. If you have a junior developer who can't make sense of the test
by dkrich 12y ago
I have to say that the trade-off argument brought up between DRY and readability is pretty lame. If you have a junior developer who can't make sense of the test because you put the test data in a separate class or are using a setup method, then teach him or her how to trace the call to the setup method and then read through it.
If we follow this logic then all code should follow the same methodology of readability because tracing through method calls is too cumbersome. Obviously that isn't the case for most code, so why would it be true for unit tests?
- woah 12y agoPart of the benefit of tests is that they are a form of documentation.
- dkrich 12y agoI don't think having readable tests and DRY are necessarily mutually-exclusive. If you name methods and variables with lengthy but very descriptive names your tests can still be readable. In fact the more you modularize your setup methods the more readable they can become. For example: TestData.CreatePerson(); TestData.AddSsnToPerson(); TestData.PersonModule.checkWhetherPersonHasValidSsn(); ...is pretty readable despite being broken up. It may or may not be true that if you just went through the setup here it may be more readable, but the benefit to this approach is that you only have to write a method to add an SSN to a person object one time and then everyone can use it without needing to understand the structure of different objects. Notwithstanding readability, I would argue that DRY makes writing tests easier than cramming a bunch of setters into every test case. Once somebody understands what a setup method does, in every place that it is used in other tests the tester can skip over that part and move on to testing their specific use case.