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
--