views:

128

answers:

4

I'm currently debugging some fairly complex persistence code, and trying to increase test coverage whilst I'm at it.

Some of the bugs I'm finding against the production code require large, and very specific object graphs to reproduce.

While technically I could sit and write out buckets of instantiation code in my tests to reproduce the specific scenarios, I'm wondering if there are tools that can do this for me?

I guess specifically I'd like to be able to dump out an object as it is in my debugger frame (probably to xml), then use something to load in the XML and create the object graph for unit testing (eg, xStream etc).

Can anyone recommend tools or techniques which are useful in this scenario?

+2  A: 

I've done this sort of thing using ObjectOutputStream, but XML should work fine. You need to be working with a serializable tree. You might try JAXB or xStream, etc., too. I think it's pretty straightforward. If you have a place in your code that builds the structure in a form that would be good for your test, inject the serialization code there, and write everything to a file. Then, remove the injected code. Then, for the test, load the XML. You can stuff the file into the classpath somewhere. I usually use a resources or config directory, and get a stream with Thread.currentThread().getContextClassLoader().getResourceAsStream(name). Then deserialize the stuff, and you're good to go.

Don Branson
Using ObjectOutputStream is a good solution unless you change your classes, then you will need to regenerate the whole object graph and serialize it again
Superfilin
Right you are. I usually leave the injected code laying around somewhere. I'd be more formal about keeping it in a work environment than on home projects.
Don Branson
+1 You could add that: 1) any form of object serialization is fragile in the face of changes to classes that affect representations, and 2) the advantage of using XML over ObjectOutputStream is that it is easier to "fix" any problems caused by this fragility using an XML or text editor.
Stephen C
+1  A: 

XStream is of use here. It'll allow you to dump practically any POJO to/from XML without having to implement interfaces/annotate etc. The only headache I've had is with inner classes (since it'll try and serialise the referenced outer class).

Brian Agnew
A: 

I don't know about Java but if you change the implementations of your classes then you may no longer be able to deserialize old unit tests (which were serialized from older versions of the classes). So in the future you may need to put some effort into migrating your unit test data if you change your class definitions.

ChrisW
+2  A: 

I guess all you data is persisted in database. You can use some test data generation tool to get your database filled with test data, and then export that data in form of SQL scripts, and then preload before your intergration test starts.

You can use DBUnit to preload data in your unit test, it has also a number of options to verify database structure/data before test starts. http://www.dbunit.org/

For test data generation in database there is a number of comercial tools you can use. I don't know about any good free tool that can handle features like predefined lists of data, random data with predefined distribution, foreign key usage from other table etc.

Superfilin
In case it wasn't clear from this: db:unit has an easy way to dump the current state of the database into any of the formats it reads.
ndp