Several successful projects exist without TDD (or even unit tests for that matter)<p>The whole of GNU+Linux for example (or at least most of it)<p>On the other hand I've seen several projects claim "very good TDD coverage" and then crash and burned when put into production (usually posted to HN)<p>Real world, real usage testing is essential. TDD is good for keeping you on track and avoid regressions<p>It's also good for complicated (small) pieces of software that do something complex and is prone to having its behaviour adjusted with time (think: reports, data consolidation or analysis, calculations, etc)
I find that simply assert'ing all non-trivial assumptions and invariants in the code is the form of unit testing that works the best in heck of a lot of cases.<p>If there's need for explicit tests, just use the code in the right way and see it exit cleanly. Then use the code in the wrong way and see it assert (first replacing the assert() with a throw/longjmp to catch failures without aborting).<p>Asserts also double as a concise context documentation. When an assert is triggered, it's typically easy to see what its condition means and what has gone wrong. So it's a win-win all around :)
I agree with the first answer.<p>I'm not a fan of unit testing. I'm just doing it because it's a requirement (and we still have no QA).<p>Why I'm not a fan? Because I'm doing my own tests. And probably it has a bias all over it. I know when it will have a successful run and I expect where it will fail. This is not the scenario that I wanted. (I know this is not a good testing scenario)<p>In my opinion, a programmer must write a good code. And leave the testing to the QA.
The thing I really dislike are unit testing styles that use mock objects a lot.<p>I see some people say that you should test each object in isolation, mocking out any dependencies. That seems wrong headed to me.<p>I prefer my unit tests to test everything all the way down.<p>The only thing I would mock is the file system, which is useful for testing file loading code.
Testing is something I do a lot, and like talking about a lot as well. There are no hard and fast answers to testing, like other stuff, there are lots of opinions(they are like assholes, everyone has them, and the others' stinks) about testing. So here goes mine(not necessarily correct, but worth putting them here). I am putting them as one liners, let me know your thoughts.<p>1. What do you mean by unit in unit tests?<p>An implementation of very basic feature, probably not more than 100 lines of code.<p>2. What do you test when you write a unit test?<p>We test the basic correctness, eg. given a url, if it exists assert 200, if not assert 404.<p>3. What should not be tested?<p>The inbuilt libraries should not be tested. Eg. If you are using a library say django, you should assume it comes pre tested and should not spend time writing tests for them.<p>4. What should be the depth of the tests?<p>There are no rules, but you should stop when you feel like you are humming inception theme.<p>If you want to read in slight more detail its <a href="http://www.blog.fruiapps.com/2012/09/An-intro-tutorial-to-test-driven-development-in-python-django" rel="nofollow">http://www.blog.fruiapps.com/2012/09/An-intro-tutorial-to-te...</a>
Kent Beck's response is interesting. How does one know that you write correct code until you realise there is a bug in it? I thought unit tests were developed for when you refactor code - at this point you run the unit tests and if any fail, you have refactored in a bug...
It's partially an answer to jiggy2011's question from <a href="http://news.ycombinator.com/item?id=4898861" rel="nofollow">http://news.ycombinator.com/item?id=4898861</a>, but I think it's worth mentioning separately.<p>There's a very good sentence in SO thread - j_random_hacker's: "Every programmer has a probability distribution of bug locations; the smart approach is to focus your energy on testing regions where you estimate the bug probability to be high."<p>So Kent Beck is not skipping some tests because he thinks he's awesome (as jiggy2011 said it sounds like); he does that because he can anticipate, from experience, that a <i>particular type</i> of bug is of very low probability for him, because he <i>knows</i> he's unlikely to make it. Like, for example, I tend not to put + instead of ++ in C++, so I can be pretty confident my code is free of these types of errors. Everyone needs to estimate his probability distribution for oneself (factoring for unknown unknowns) and test accordingly. The more experience one has, the better the estimate.
A good strategy I've found was suggested by Reid Burke in response to this answer:<p><a href="http://reidburke.com/2012/09/27/write-code-that-works/" rel="nofollow">http://reidburke.com/2012/09/27/write-code-that-works/</a><p>Your code isn't uniform, and so you shouldn't be expecting 100% code coverage on everything either.<p>Instead, assign to particular sections of your code levels of stability, and for the code that has the highest stability/least amount of expected future change, prioritize writing the most unit tests for those.
> "If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it."<p>Hmm, that sounds like the old "You don't need to test , just be an awesome programmer duh!" argument.<p>The kind of mistakes you never anticipate making are probably the sort of stuff you should be testing for.<p>The amount of times I've had something fail on an edge case that turned out to be a typo in a var name on some edge case somewhere..
Well. I use a lot of unit testing because the idea of testing small pieces of code works for the way I develop software at work - modified pair programming. Instead of reviewing Holmes's code Watson writes tests (mostly unit ones).<p>At spare time, tho, I tend to be too lazy to write a lot of tests(most of my "projects" are too small and never get released to the public anyway)
I try and cover the easy 80% where it's helpful, and then specific things in the difficult 20% on an as-needed basis, or when bugs are discovered. It's an asymptotic curve: you want to spend the effort for the low-hanging fruit, but not get caught up chasing after that time-eating final bit of coverage.
A lot of the comments say tests are needed for edge cases and discovered bugs.<p>How does this compare with TDD?<p>Has anyone tried both? How did it work out for you? I implemented TDD for a project and I thought it was overkill and took a considerable amount of my time.