| > I am against writing unit tests in general, since experience shows that they actually prevent high-quality code from emerging from development--a better strategy is to focus on competence and good design. False dilemma. Are competence and good design exclusively from people that don't TDD? > The basic idea--amazingly, one of the most popular methods of software engineering (and growing in popularity!)--is that, after you figure out what you want to do and how you want to do it, you write up a set of small test programs--each testing some tiny piece of the program that will exist. Then, you write the program. No. You are wrong. It is not that. > Let me emphasize: you write the test cases for your program, and then you write your program. You are writing code to test something that doesn't even exist yet. I am not rightly able to apprehend the kind of confusion of ideas that could provoke such a method. You are writing specifications for a program that doesn't exist yet!? Nuts. > The most important argument is a practical one: Test-First doesn't work. It doesn't work because it doesn't work. Sad argument. > I was once one of these newly educated kids. So, for a few years, I worked exclusively with the Test-First strategy. When it was over, the results were undeniable. The code--all of it--was horrible. Class projects, research code, contract programs, indie games, everything I'd written during that time--it was all slow, hard to read, and so buggy I probably should have cried. It passed the tests, but not much else. So it didn't work for you so it is everybody else's problem but yours. > So this is the first reason TDD fails: You're trying to make a design before you learn anything about it. No. You are not. Indeed, depending on how you decide to do your tests you should be able to change your design and the underlying implementation and no test should break. Please, take a look to the outside in approach. > Week 3-4: Write tests. > Week 5-10: Write code. Oh my god. This is terrible. And no, this is not TDD either. This is inverse waterfall :P > Even if you somehow succeed, TDD prevents incremental drafts by functionally requiring all tests for a module to pass before you get any real results. Probably this is a misconception too. You don't write all the tests before. One test, small implementation pass, another test, small implementation pass... You get the results incrementally. > There is literally no substitute for competence. If your coders don't have it, TDD won't fix it. I fully agree on this. And probably this is a really common misconception. But false dilemma again. I don't think TDD came in this world to turn bad programmers into good programmers. It is just another tool in the toolset. You can have terrible programmers that do TDD and excellent programmers that do it. My recommendation: https://vimeo.com/68375232 |