Thursday, September 07, 2006
Teaching TDD
I'm currently in the process of formulating a new Unit Testing and TDD course. This is a course which I have a hard time giving -- its the one course I teach where I've gotten consistently bad reviews :(.
One problem with teaching TDD is that its not like teaching the Java language where you can focus on teaching syntax (and have the compiler enforce the rules of the syntax). Its similar to teaching OO (Object orientation) because its also about teaching concepts.
Teaching TDD is also made much more difficult because you're also teaching a process (this is in contrast to just teaching how to write Junit tests -- although part of teaching TDD is just that -- teaching the mechanics of writing Junit tests) and trying to convince the participants to adopt the process.
The hardest part lies in that you're trying to change something very ingrained in a programmer -- the very way he or she writes code. Along with the initial difficulty of learning the tools (figuring out Junit and other unit testing libraries) and skills (how to write tests, refactoring, etc), it also means undoing habits that have long been part of the programmer's way of working.
In addition, the programmer might also be trying to figure out how to implement TDD in their ongoing project, and worrying about how it impacts their project plans and estimates, as well as puzzling over how to actually implement it with an existing code base that has no unit tests.
All of these things conspire to make teaching TDD very difficult.
One problem with teaching TDD is that its not like teaching the Java language where you can focus on teaching syntax (and have the compiler enforce the rules of the syntax). Its similar to teaching OO (Object orientation) because its also about teaching concepts.
Teaching TDD is also made much more difficult because you're also teaching a process (this is in contrast to just teaching how to write Junit tests -- although part of teaching TDD is just that -- teaching the mechanics of writing Junit tests) and trying to convince the participants to adopt the process.
The hardest part lies in that you're trying to change something very ingrained in a programmer -- the very way he or she writes code. Along with the initial difficulty of learning the tools (figuring out Junit and other unit testing libraries) and skills (how to write tests, refactoring, etc), it also means undoing habits that have long been part of the programmer's way of working.
In addition, the programmer might also be trying to figure out how to implement TDD in their ongoing project, and worrying about how it impacts their project plans and estimates, as well as puzzling over how to actually implement it with an existing code base that has no unit tests.
All of these things conspire to make teaching TDD very difficult.
