|
|
|
|
|
|
by theforgottenone
4418 days ago
|
|
|
They didn't highlight the key property of a project for when tdd works and when it doesn't: when you know the requirements with clarity (compilers, stacks, etc) it is possible to use tdd since the tests will map back to well understood requirements. But when you don't (like building a website with fussy browsers, or writing a log file parser with format anomalies), you don't have the foresight needed to write the test before the code. I think the notion that you (eventually) get to broad code coverage in a full test pass with a single pushbutton test, that Fowler talked about, is the best idea. I think that whether to use mocks is really dependent on your particular environment, and the penalty of not using them. I've had to mock legacy servers that I couldn't touch in testing, and they helped there a lot. Also ones with really slow IO, or bizarre security requirements that make impersonation in test difficult or impossible. |
|
|
Actually, I think TDD is particularly useful in the last case (writing a log file parser with format anomalies) since you end up with a lot of edge cases where, before you can code to handle each of them, you have to determine exactly what the code should do for each case, often without a clear logical superstructure that explains it all. So you of necessity are incrementally developing a set of test cases before you code to handle each of them -- so if you codify them as automated test cases before you code each, you not only get testing that you handled the new case right, you also get regression that you didn't break the previous ones with the change.