Originally posted by Mark Dexter:
I'm working on a project that involves converting large files from one format (e.g., RTF) to another (e.g., a proprietary XML-based format for visually-impaired people called DAISY). It is not clear to me the best way to organize tests for this type of application. [...] How can we break this down into small unit tests?
My question is: Does your book provide examples, strategies, etc. for testing this type of application?
No, the book doesn't provide examples of this specific type of domain but I'll try to describe how I'd try to approach this scenario.
First of all, the suggestion about validating the output is a good one. I probably wouldn't do this for all output, however, because I'd like to keep the test suite fast. I'd probably try to create a sufficiently complex document with the most essential features to be converted and validate that output.
Second, I'd try to avoid comparing the full document as much as possible. Instead, I'd look for a design that lets me have smaller converters for individual features that I could test drive in isolation and against a simple, small document model. I'm not sure if this would make sense in your specific case (converting RTF to DAISY), though.
Originally posted by Mark Dexter:
For example: How do you manage test resources, such as before and after files? How do you validate the after format to make sure it is correct?
Most often I place my "before" and "after" files next to the test class that uses them, named after the test class to keep them next to each other.
However, sometimes it's better to organize the test data in a separate directory tree. Situations where I do this include those where I tend to reuse the same data files between multiple tests.
Regarding validation, I'll throw the question back at you. How do you know the expected output file is correct?