Learning to code is hard. Learning to code with tests is harder. Let's practice this art together.
Tests can serve different purposes:
- Design aids
- Documentation
- Regression checking
And there's at least one more that I'm not thinking of at the moment... but the point being, a test that serves #1 but doesn't help #2 or #3 much can be a great test to write and then an equally great test to delete.
In my mind a throwaway test is something you just slap together to see how something is working and after you know you don't care anymore because you assume -for whatever reason- that it isn't going to change.
Haha
but that's a good point ... What does a throwaway test look like to you
I wrote a test to tell me how many directories get returned by Directory.GetDirectories if I point it at my C drive. I did this only to find out how that method works; incidentally I found out how many (98). Now I can throw that test away because it's not testing anything I care about.
what - in my opinion - you're describing as throwaway tests are what Justin Searls - in this very excellent talk from RubyConf (http://blog.testdouble.com/posts/2015-11-16-how-to-stop-hating-your-tests.html)
...described as "crappy tests"
was shut down after a year of development and some use
I don't like to play the "best practice" card, but it's tremendously valuable. Often a small change in the production code can eliminate giant terrible swaths of test code.
i can see purists fighting back, but I think it's overwhelmingly worth the drawbacks
I work in a hardcore TDD shop so that viewpoint seems utterly alien
in theory that clutters up the code and increase page size
but that's a pretty far stretch IMO
Hmmm... I agree that it becomes a lot more important if you practice TDD, but I've worked with developers who were suspicious of TDD but valued loosely coupled and swappable components. I've also seen TDD proponents argue that the design changes you make in response to wanting to unit test things are part of what makes TDD a valuable practice.