Timeline for How can I write unit tests that simplify feature implementation?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 19, 2015 at 11:08 | comment | added | Jon Hanna | That second way isn't unit testing at all, because it's not testing a unit. It's idea testing. Idea-testing ("hey, if I try this, will it work") can be very useful, but it's testing an idea, not a unit or any other produced software. | |
| Jun 18, 2015 at 19:55 | comment | added | Warbo | @rwong indeed, I wrote something similar but removed it to make my comment fit fit the limit. That kind of copy-paste is often done in documentation too, but in the context of the question that would add even more of a maintenance burden :) Also, it's perfectly possible to do testing without TDD, eg. adding in tests retrospectively. It's all a matter of cost/benefit tradeoff; the key is to try and understand those costs and benefits, rather than ignore potential solutions or follow doctrines religiously. | |
| Jun 18, 2015 at 18:12 | comment | added | rwong | @Warbo: The second approach is suitable as a temporary, throwaway test harness for use during prototyping, much like a scaffolding does when constructing a building. This alone does not invalidate the need for having a sound architecture and a long-lasting unit test suite. TDD is suitable if one knows what to assert next; but sometimes there is a stalemate where the only way out is write some (throwaway) code and see what it does. I speak this from algorithm research perspective - too many people think algorithm means copying from a textbook; it's not. | |
| Jun 18, 2015 at 15:44 | comment | added | shuttle87 | I have to agree with Warbo here. Tests are only because of what they tell you about the state of your main code base. If your tests are using different code then what exactly are they testing? How is this useful for your project? | |
| Jun 18, 2015 at 15:33 | comment | added | Warbo | Your second approach sounds like a bad idea. Tests only exist to check the project's code. Having a green test suite on a broken project is worse than useless: it gives false information. It's much better to make the tests call the real project code, even if they all fail. The goal is not to have a green test suite, it's to have a working project. | |
| Jun 18, 2015 at 14:28 | review | First posts | |||
| Jun 19, 2015 at 7:33 | |||||
| Jun 18, 2015 at 14:27 | history | answered | Sathen | CC BY-SA 3.0 |