How to preserve an in memory datastructure to later use it in a Unit test

Question

Hi.

In my code, I am occasionally passed various byte arrays and such. Also, they may be managed objects. I would like to preserve those memory structures so that I can write test cases against the concrete examples.

My standard approach is to hit the breakpoint, use the debugger to find the various values and then either new them up or embed a file or something in the unit test assembly as a resource. Sometimes, this involves writing my own abstraction of the component interaction to make my code depending on something that can be new'ed up.

Is there an easier way? I cannot imagine that this is something new. Let's say that you are given a fire central unit to communicate with. You play around with it to make it produce its datagrams, which you want to create for your unit tests. Also, when you encounter a bug due to some undocumented way that the fire central is composing its composite messages, you want to record and preserve those examples.

Ideally, I would like to be able to record all interaction to my code and then pick and choose various playback scenarios. But just getting the various datagram examples in-memory from the debugger and put it back into a unit test would help me a lot.

Any suggestions?

Answer 1

Try with binary serialization.

The above is specifically for the part where you want to save/load the info or some objects holding info that you use to test the interaction with that external system. I prefer to call those tests focused integration tests, to better capture the difference of focus from the unit tests of the rest of your code with other logic you may have.

Try to separate the code that does the specific integration with the external system from the rest of the code in your system. I suggest to put it behind an interface, that you can replace/mock when creating your unit tests for the rest of the system. This way you can have specifically crafted scenarios that test several aspects/logic of your code without hitting the external system - which also means you can run lots of them in seconds.

Answer 2

As Freddy Rios hints in his answer, you need some way of persisting the in-memory object so that you can reuse it from your unit tests. The Memento design pattern is a good start, and serialization is the default .NET way of implementing it.

That leaves the question on how to easily capture those objects. Here's an approach that you can try:

Abstract the communication to and from your resource behind an interface. That is always a good design decision.

When you do that, you can use the Decorator design pattern to wrap your real implementation of that interface. This means that you can create a Decorator that simply records (serializes) the interaction, but delegates all calls to an underlying implementation after it has recorded the objects in question.

When you troubleshoot, you can hook your code up to the Memento Decorator and later pick up the files whereever they where written. For production code, you simply skip the Memento Decorator and directly use the real implementation.

If you want to be really fancy, you can even implement the Memento Decorator so that it emits unit test code that mimics the interaction that was recorded, but this is likely to require a fair amount of effort...