"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.