Q: Why is TDD a good idea when bug fixing?
A: Because sometimes the amount of work required to make a "red test" is so much that if you fix the bug first, you will never get around to writing the test infrastructure. (Plus, after you fix the bug, you don't have a good test case for writing that infrastructure.)
Case in point: I have an oData service which fails on certain queries, because the underlying CRM provider which services the queries can't handle certain LINQ expressions. There are likely to be other queries which fail in the future, and I need automated tests to prevent fixed queries from regressing as I tweak my oData service... but the bug repro I have is too heavyweight for a unit test. So instead of fixing the bug I just spent (three? five?) hours digging through dependencies with ILSpy and writing enough test infrastructure that I now have a failing "red test" to document the bug condition... only uses it uses mocks and reproes the bug without any network communication at all.
It's amazing how good I feel about the progress I've made even though the bug itself is still RIGHT THERE.
(Also, git's branch-per-feature paradigm is great for keeping my cognitive load modest while doing TDD.)
--
Deck thyself now with majesty and excellency; and array thyself with glory and beauty.
Cast abroad the rage of thy wrath: and behold every one that is proud, and abase him.
Look on every one that is proud, and bring him low; and tread down the wicked in their place.
Hide them in the dust together; and bind their faces in secret.
Then will I also confess unto thee that thine own right hand can save thee.
I could not love thee, dear, so much,
Loved I not Honor more.
A: Because sometimes the amount of work required to make a "red test" is so much that if you fix the bug first, you will never get around to writing the test infrastructure. (Plus, after you fix the bug, you don't have a good test case for writing that infrastructure.)
Case in point: I have an oData service which fails on certain queries, because the underlying CRM provider which services the queries can't handle certain LINQ expressions. There are likely to be other queries which fail in the future, and I need automated tests to prevent fixed queries from regressing as I tweak my oData service... but the bug repro I have is too heavyweight for a unit test. So instead of fixing the bug I just spent (three? five?) hours digging through dependencies with ILSpy and writing enough test infrastructure that I now have a failing "red test" to document the bug condition... only uses it uses mocks and reproes the bug without any network communication at all.
It's amazing how good I feel about the progress I've made even though the bug itself is still RIGHT THERE.
(Also, git's branch-per-feature paradigm is great for keeping my cognitive load modest while doing TDD.)
--
Deck thyself now with majesty and excellency; and array thyself with glory and beauty.
Cast abroad the rage of thy wrath: and behold every one that is proud, and abase him.
Look on every one that is proud, and bring him low; and tread down the wicked in their place.
Hide them in the dust together; and bind their faces in secret.
Then will I also confess unto thee that thine own right hand can save thee.
I could not love thee, dear, so much,
Loved I not Honor more.
No comments:
Post a Comment