• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Test Driven - organizing resources

 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks very much. I will look into this. Mark
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic