Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Test Driven - organizing resources

 
Mark Dexter
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Lasse. 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. 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? 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? Thanks very much. Mark Dexter

[edited to use a meaningful subject line - was "Another Lasse question"]
[ September 24, 2007: Message edited by: Jeanne Boyarsky ]
 
Charles Hasegawa
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not to get in the way of the author's response, but you might want to look into XMLUnit. XMLUnit is an extension to JUnit that lets you validate XML. If you have a schema (XSD) or a DTD for your XML, that is your first check (that the XML generated validates). Assuming that your XML is "valid" you then use XML unit to verify that the data has been parsed/transformed correctly. You do this by comparing the generated XML against an expect XML result.

There is a pretty good article on this exact thing at developerWorks
 
Mark Dexter
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks very much. I will look into this. Mark
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic