[Tutor] duplication in unit tests

[Serdar Tumgoren]

> Yes, this is much better. Notice how much less code it is! :-)

Yes, it was amazing to see how much code melted away when I gave up on
the OO design. As you and others suggested, clearly this was not the
correct approach for this portion of my program.

> If you expect unicode input then it makes sense to test for it. If you
> don't expect unicode input, it might make sense to test for an
> expected error - how do you want the function to behave with invalid
> inputs?

For invalid inputs, I'd like to log the error and place the data in a
file for additional review. The input has to be unicode, and if it's
not, it means my initial read and decoding of the source data was not
performed properly. For that case, I'll plan to raise an exception and
abort the program.

You could add other tests as well, for example does it work if
> there are two dashes in a row? Does splitLines() correctly remove
> blank lines?

So it seems I have a healthy list of test cases to start with!

> By the way I applaud your effort, unit testing is a valuable skill.

I'll admit, I learned the hard way on a project earlier this year. I
got that project done (again with the help of folks on this list), but
didn't do any test-writing up front. And now, as the inevitable bugs
crop up, I'm forced to patch them hoping that I don't break something
else. It drove home the fact that I need to get serious about testing,
even if I don't go full-bore TDD on every project.

I suspect an overdose of preparatory TDD reading had my head swirling
a bit. I appreciate you all walking me through this first effort.

No doubt I'll be writing again soon with more questions. Meantime, many thanks!

Serdar