A good practice is to reverse assertions while you're writing a test. If x is supposed to be false then assert that it's true. The test should fail, but sometimes it doesn't and you realize that your test has a bug or that you've already found a bug in the production code.
Before becoming test-driven I would manually test my stuff, using my judgement to determine the scope of what I'd test. When I became test-driven I saw how writing those tests was like writing the code on the other side of the coin. The design is so clear and beautiful when it's exercised in a suite of tests. I enjoy writing (unit/transactional) tests because it proves how awesome my code is, and is much better at keeping it that way than I am while I'm busy building something more interesting.
That is a sweet app, not a sweet pad.
s/\?\?\?/online as "Tom Cruise" and tried selling "Katie's used panties" for $100 each/
I'm always looking for a new idea that will be more productive than its cost. -- David Rockefeller
