He gave a very colorful presentation on vast ranging topics on professionalism and software development.
His driving point was we as software professionals are ultimately responsible for what we deliver and that is code. There can be no valid excuse for sloppy work. It’s too easy to take refuge in tight deadlines and unreasonable managers.
I am also reading a book by him- Clean code , after Horea recommended to me. Though I have just read the first chapter so far- that seems to be a promising read
One thing that didn’t resonate well with me was Robert’s views was on TDD. I fully appreciate the benefits of Unit testing framework- but I found it difficult to reconcile with TDD as he explained it
As he explained- TDD has three laws
1) Do not write production code for which you do not have a unit test
2) Write only enough Unit test as is sufficient to fail the production code. And then stop.
3) Write enough Production code to pass the unit test. And then stop.
So as per this.. when you start coding on clean slate- you can’t start with Production code (See rule #1) and so you start with Unit test- as soon as you write a single line invoking production code which doesn’t even exist yet- you are done (Rule #2 kicks in at this point). In fact at this point you will get a compilation error !!! Now you move to Production code and write that class- then you stop- because you have satisfied the Unit test. See rule #3.
So practically – if you follow this discipline- you will be alternating between Production code and Unit test- like 30 seconds each. At any point you will write only few line of code at a time- Production or Unit test
Whew !!!. This sounds extreme to me. Way too extreme actually.
These are my problems with TDD
1) How do you test for possible bugs in Unit tests ? write more Tests for that ?
2) The developer who coded a bug in Production code- why won’t he not introduce a similar bug in Unit test
3) Unit testing is important- but how do you define that unit. Do we define each line as a unit- because that’s what we seem to be trying to do. I disagree that each and every line of code needs to be unit tested. Units can be more granule than a line of code
I think Unit tests are an excellent resource for preventing breakages and regressions and come in very handy especially before and after undertaking a re-factoring exercise.
And then I came across another interview at InfoQ- . Now Luke Francl is speaking closer to what I think
He basically says that Unit testing is not end all means of software quality. He stresses a great deal on code reviews by peers, usability tests.
Oh well. I haven’t ever used strict TDD ever. Maybe some day…