"Phlip" <phlipcpp / yahoo.com> writes: > Eric Schwartz wrote: > > I know I should have written my tests first, but I didn't, so now I'm > > trying to do them after the fact. > > The best way to do this (in my exalted opinion) is to point the tests at an > empty project, use the testless project as a reference, and write tests that > force you to copy tiny bits of code from the testless project into the empty > project. Unfortunately, that works out to effectively rewriting the code from scratch, which is (alas) not terribly feasable at the moment. > Dave Astels (who I suspect wrote a book about TDD) and I pretended to have a > vicious fight over this subject. > > He claimed to only do one (1) assert per test case. I made him admit this is > a goal, not a rule. That certainly was the goal I went for. But it seems to me that if I've got a method which is supposed to create a file with a specified format and data, isn't it reasonable to first assert() the file exists, then to assert() its format is correct, and finally to assert() the data in it is what you expect? I'm not sure how one would make these separate tests. Or rather, I can guess how you might do that, but it seems a bit absurd for the sake of correctness to run the exact same code three times just so you can say you didn't run more than one assert() per test case. > If you try to approach that goal, you will maximize re-use and encapsulation > of your tests' setup code. It grows into resplendent fixtures and resources > in the test case. Well, this was exactly my goal; it's just that given the above situation, I didn't see any (to my mind) reasonable way around it. > I hope nobody's as tired of the following anecdote as I am of telling it: <snip illuminating fax story> > Uh... what was your question again? Heh. I can certainly create a mock object to pretend to be a close of TMail, which will solve 80% of my problem, but this still doesn't answer two important questions: 1) Has the interface to tmail changed? How can I tell? 2) Is my mailserver config screwed up? I think I care less about 2), because if the mailserver on my test host is screwed up, I'm going to have a number of problems that should shortly become obvious. I'm not sure how to test 1) without actually sending an email. > Nix. Send to a common office account, or a Yahoo account, or > something. But then, how can the test verify that the email got there? All it can know is if it thinks it was sent properly. Again though, given my previous paragraph, I think I most likely don't care. > Or register each tester, and let them put their favorite addy in a > configuration file. And if the configuration file isn't set up? I assume the test fails... and then you get into much harder problems, as someone could easily set up an email address in their configuration file that I could have no way of knowing how to check. > Tests >must< run unattended. Everyone needs the minimum > possible excuses not to run all the tests, all the time. I know, that's why I *really* didn't like my 'solution', but couldn't think of any way around it. But using a mock object for the email will solve most of my problems, as my concern when testing my TestItem class should not be whether or not the mailserver works, but whether TestItem is doing what it thinks it should. > > Other than that, I'm enjoying Test::Unit quite a lot. > > It's a trip! Yeah, it reminds me a bit of when I first learned OO-- it took a month or two to truly understand the difference between an object and a struct with function pointers. (Which is to say, on the one hand: none. On the other: everything.) If I force myself to write test-first in the future, it'll be a lot easier in the long run. -=Eric -- Come to think of it, there are already a million monkeys on a million typewriters, and Usenet is NOTHING like Shakespeare. -- Blair Houghton.