I only sometimes write automatically evaluated tests.
One thing that appeals to me about the idea of TDD is that perhaps it seems like a puzzle or game to pass some (easy to create) test. That is, the feedback is free once established.
Since I’m good at finding and fixing bugs without an always-run suite of tests, I don’t bother creating them at all for most small programs (some of which are easy to implement correctly, but annoying to automatically test comprehensively). At some scale or difficulty, my abilities will fail and I will definitely profit by building some routinely-run tests.
A halfway territory between automated tests and blind hope is to generate routinely produced summaries that can be evaluated easily by a human for correct-feeling. E.g. for graphics, you show the picture. This can eventually morph into a regression test (you freeze the report format and save the output produced from the inputs). If it’s just a small step to add some automatic consistency checks as the report is produced, then I of course do so.
Jonathan—one of the reasons to write unit tests is so that programmers other than you can see what your code is designed to do (for occasional values of “programmers other than you” that includes you when you’re not at your best). Inheriting someone else’s bad tested code is much less painful than inheriting someone else’s bad untested code.
(And I humbly observe that a larger proportion of the untested (or sparsely tested) code I’ve inherited has been bad than the tested code that I’ve inherited.)
I agree that automated tests are more important in multi-person projects. I do value whatever tests exist in projects I’ve worked on (including my own solo stuff); I just don’t always choose to spend the effort creating them.
A halfway territory between automated tests and blind hope is to generate routinely produced summaries that can be evaluated easily by a human for correct-feeling.
Agreed. This is especially important for very human-oriented software (graphical programs) and pieces of software (user interfaces), because those are hard to test without an actual human involved.
I program without TDD.
I only sometimes write automatically evaluated tests.
One thing that appeals to me about the idea of TDD is that perhaps it seems like a puzzle or game to pass some (easy to create) test. That is, the feedback is free once established.
Since I’m good at finding and fixing bugs without an always-run suite of tests, I don’t bother creating them at all for most small programs (some of which are easy to implement correctly, but annoying to automatically test comprehensively). At some scale or difficulty, my abilities will fail and I will definitely profit by building some routinely-run tests.
A halfway territory between automated tests and blind hope is to generate routinely produced summaries that can be evaluated easily by a human for correct-feeling. E.g. for graphics, you show the picture. This can eventually morph into a regression test (you freeze the report format and save the output produced from the inputs). If it’s just a small step to add some automatic consistency checks as the report is produced, then I of course do so.
Jonathan—one of the reasons to write unit tests is so that programmers other than you can see what your code is designed to do (for occasional values of “programmers other than you” that includes you when you’re not at your best). Inheriting someone else’s bad tested code is much less painful than inheriting someone else’s bad untested code.
(And I humbly observe that a larger proportion of the untested (or sparsely tested) code I’ve inherited has been bad than the tested code that I’ve inherited.)
I agree that automated tests are more important in multi-person projects. I do value whatever tests exist in projects I’ve worked on (including my own solo stuff); I just don’t always choose to spend the effort creating them.
Agreed. This is especially important for very human-oriented software (graphical programs) and pieces of software (user interfaces), because those are hard to test without an actual human involved.