Everah wrote:Ok, I never intended this discussion to head down the TDD path, but since it has taken that turn maybe we can look at it a little closer. My understanding of TDD is rather limited so I am throwing this out there as a series of questions...
I think my point Everah, was that heading in the TDD direction first is a bad idea for most people. If you look at what you posted -- the code is first and the tests are second. You did not use TDD to design. In fact you could not use TDD to design because you don't know how to test well yet. My suggestion is: learn to test first ... use that to improve your design skills ... then learn to combine them.
Chris Corbyn wrote:I think this was the key point -- starting from the start. If you've never TDD'd before, trying to start halfway through a project will just put you off. Mostly because everything that was developed prior to the employment of TDD won't be very test-friendly.
The reason is that TDD is a DESIGN practice, not a coding practice. That is regularly forgotten and not mentioned in this discussion. And GOOD DESIGN is an almost impossible thing to teach. As I said, 2% are natural at it; many others learn it the hard way; most never really design well.
Chris Corbyn wrote:I think (b) is the most important thing to get the hang of. ~arborint's first example he posted was a good demonstration of where you can trip up. Although this was only for testing a really simple concept, there were tests for two different scenarios/behaviours in the same test method. In a more complex scenario a failing test with multiple behavioural expectations in it would cause confusion. The more methods you have like that the worse if gets.
That's because I was not doing TDD. I was giving some examples of the thought processes that unit testing makes you go through. Writing unit tests gets you to look at your code differently. In this case it exposes the design. That's not tripping up at all. That is a step to understanding design that you need to do before ever understanding TDD.
Chris Corbyn wrote:Writing unit tests very badly often just makes your work load increase since you spend more time maintaining your broken tests than you do maintaining the source code. I can give a classic example of something I fix in other people's tests at work all the time. We have some actual system tests (to supplement our units) which really do connect to a database full of test data. Before each test method runs the DB is wiped and the schema/data is re-imported. A common fragile test scenario I run into with this set up is people making assertions about exact row counts in the test data. Of course, when someone adds their own test data this breaks that test. There are all kinds of things you can do badly which just cause tests to break all the time when the system still works as expected... learning to avoid the situations just comes with practise.
Again, you like most people who understand testing are very quickly way out in front of what anyone trying to understand testing can practically understand. You are telling people that don't yet know how to test that writing poor test is worse than no tests -- but they will start by writing poor tests. So you have given them a reason to stop testing because it takes some time before you start writing test at the level you are discussing. This gets back to my point. Testers who never had to crawl because they just got it have a hard time understanding that most people need to crawl first.