Paul wrote: >It seems to me that a big reason for developing via writing tests first >(Test Driven Development) is that the tests serve as a debugging tool -- >if a test breaks, then the last piece of (non-test) code that change is >likely the culprit. But with the powerful debugging environment that >comes with Smalltalk, I am wondering of the utility of TDD (TDD is big >in the Ruby camp perhaps for a reason). After all, writing and >re-writing the tests becomes quite a non-trivial chore (not to mention >that the tests themselves could be buggy). So my question: Is it ok in >Smalltalk to write tests afterwards? Is it even perhaps recommended?
Test-driven development works well when you have some idea of where you want to go. If you don't know yet what your first test could look like, the powerful debugging environment of Smalltalk allows you to do some fast experiments. Then you might want to switch to TDD, as there are two ideas in TDD that are not covered by having a good debugging environment: - don't write more code than you have tests for, so the design is really driven by the tests - the tests provide insurance that you'll notice when something breaks. Writing and re-writing tests is what helps you get to a simple design. Tests need refactoring and DRY just as much as other code. Stephan
