Save object in debug and than use it as stub in tests

My application connects to db and gets tree of categories from here. In debug regime I can see this big tree object and I just thought of ability to save this object somewhere on disk to use in test stubs. Like this:

mockedDao = mock(MyDao.class);
when(mockedDao.getCategoryTree()).thenReturn(mySavedObject);

Assuming mySavedObject - is huge enough, so I don't want to generate it manually or开发者_开发知识库 write special generation code. I just want to be able to serialize and save it somewhere during debug session then deserialize it and pass to thenReturn in tests. Is there is a standard way to do so? If not how is better to implement such approach?

---

I do love your idea, it's awesome!

I am not aware of a library that would offer that feature out of the box. You can try using ObjectOutoutStream and ObjectInputStream (ie the standard Java serialization) if your objects all implement Seriablizable. Typically they do not. In that case, you might have more luck using XStream or one of its friends.

---

We usually mock the entire DB is such scenarios, reusing (and implicitly testing) the code to load the categories from the DB.

Specifically, our unit tests run against an in-memory database (hsqldb), which we initialize prior to each test run by importing test data.

---

Have look at Dynamic Managed Beans - this offers a way to change values of a running java application. Maybe there's a way to define a MBean that holds your tree, read the tree, store it somewhere and inject it again later.

---

I've run into this same problem and considered possible solutions. A few months ago I wrote custom code to print a large binary object as hex encoded strings. My toJava() method returns a String which is source code for a field definition of the object required. This wasn't hard to implement. I put log statements in to print the result to the log file, and then cut and paste from the log file to a test class. New unit tests reference that file, giving me the ability to dig into operations on an object that would be very hard to build another way.

This has been extremely useful but I quickly hit the limit on the size of bytecode in a compilation unit.