No, unit testing doesn't imply TDD. Although TDD does imply unit testing.I dont get that -- unit testing was around for decades before the TDD methodoligy appeared. What's hypocritical about writing tests after you write code?The thing with unit testing is if you use it you almost have to do TDD then, otherwise it's sort of hypocritical. And to do unit testing/TDD correctly you'll have at a min about 4 tests per unit.
The number of tests, generally, should be more dependent on the number of branch conditions you wish to test than some random number picked out of a hat. Code coverage is the main thing you want to ensure with your unit tests.As for the number of tests, 4 seems pretty arbitrary..? In my engine, the internal assertion macro is hooked up to the testing framework, so I just write one test per 'unit' that calls all methods / demonstrates each usage, and asserts he results are as expected. If these test assertions or the units internal assertions fail, the test fails.
That's fine by me. I've been doing unit testing for quite a long time now (last decade or more?) I've tried TDD as well, and for some projects it has worked out great. It DOESN'T tend to work out so great though when you're dealing with a pre-existing code base.Like in TDD, I hook my tests up to the compile button, so a test failure is reported the same as a compilation failure (with file/line numbers), but I usually write them after the code, or concurrently, instead of before like in TDD.
Error checking, and similar behaviors SHOULD be part of your code, not part of the unit tests. But unit tests should be able to be extracted from the code, mainly for use with integration testing suites, and for use with the rest of your documentation.There's no reason you can't write your tests in the same source file as the unit if you feel like it ;PThis means you are bouncing back and forth from your test project to your production project about every 30 seconds to a min. Some tests you might have to stop and think about what you want to write.
As above, a IMHO a large part of your tests should be taken care of by assertions that are internal to the unit anyway, and not part of the test.
Exactly.The point of TDD is that it makes you stop and think about the use case (what to write for the unit) before writing anything, but often this is true anyway. E.g. You're writing some code that requires a hash-map lookup, but you don't have a hash-map class (for some odd reason) - at that point, you've already got a production use-case for what the hash-map class is required to do, much like what your TDD code would give you.