Hey, He claims that just because you have guard rails you shouldn't stop paying > attention and expect them to save you. >
Being someone who practices TDD, I fully agree with that. It is not because you wrote tests first and got a 100% coverage that you proved your code to be correct and bug free. That tests can prevent all bugs or that they prevent the need to to think about what you are doing are two common arguments made against a mythical strawman version of TDD. They are both clearly fallacious and not the goal of TDD or writing tests in general. [0] 4. Don't write automated tests at all and do lots of code reviews and > manual testing. Sometimes this is really the most sensible thing. I'll > leave it to you to figure out when that is though. > Absolutist statements are typically wrong. There are almost always cases in which some practice is not applicable. However I strongly disagree with your recommendation of not writing tests and automating them. I disagree even stronger with the notion that manual testing is generally something you want to do. I've seen many experts in the field of software design recommend strongly against manual testing, and am currently seeing the same theme being pretty prevalent here at the International PHP Conference I'm currently attending. So my question is not "how do we write code that is maximally > testable", it is: does convenient testing provide sufficient benefits > to outweigh the detrimental effect of making everything else inconvenient? > This contains the suggestion that testable code inherently is badly designed. That is certainly not the case. Good design and testability go hand in hand. One of the selling points of testing is that it strongly encourages you to create well designed software. > I'm not convinced that unit testing is worth doing down to the level > > of detail implied by that blog post. Unit testing is essential for > > certain kinds of problems -- especially complex problems where the > > solution and verification can come from two different (complementary) > > directions. > > I think testability is important, but I think it's not the only (or even > main) > reason to support the principles from that post. I think these principles > are > also important for maintainability and extensibility. > > Essentially, they enforce modularization of code in a way that makes all > parts > as independent of each other as possible. This means they can also be > understood > by themselves, and can easily be replaced. > There are other advantages to writing tests as well. Just out of the top of my head: * Regression detection * Replaces manual testing with automated testing, saves lots of time, esp in projects with multiple devs. Manual testing tends to be incomplete and skipped as well, so the number of bugs caught is much lower. And it does not scale. At all. * Documentation so formal it can be executed and is never out of date * Perhaps the most important: removes the fear of change. One can refactor code to clean up some mess without having to fear one broke existing behavior. Tests are a great counter to code rot. Without tests, your code quality is likely to decline. I'm sure I missed some other good points. Lots of great literature on the subject out there btw. [0] http://codemanship.co.uk/parlezuml/blog/?postid=1170 Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
