In this post I want to present a solution that, I am using to test serialization in one of my projects. This project is a web application and a lot of communication is performed through JSON formatted messages. It is really important to be sure if it is working. With serialization we can only find potential mistakes and errors on the runtime. By finding problems early you can eliminate more complex and costly bugs in the future. <h4>Json Serialization</h4> <p>For serialization, I am using Json.Net it is quite popular and stable library. All my objects that are being serialized, implement IJsonable interface. This gives me easy way to find and check if particular class is serialized somewhere.  It is very important information. At my company we had recently problem with some objects because someone wasn’t sure if one of the class is serialized or not. This caused some “unsupported” behavior on the server that was desterilizing data. <p>  <p>This interface contains only one method returning just object. With this solution, I can return either anonymous type or another class, typically DTO ( Data Transfer Object ) that contains only simple easily serialized data (eg. Value Types ). <h5>Example:</h5> <p> <p>This is quite simple model. It contains four simple types and DashBoardControlType, it is just an Enum. Method ToJson() is used to create anonymous object. In this example I am creating anonymous type. <p> <p>This object is then used with Json.Net library to create JSON string. <p>One of the problems with serialization is that errors are noticed on the runtime. If my program compiles it doesn’t mean that I won’t have any problems. One of the common mistakes in classes being serialized, is too complex logic. For instance one class can have some value dependent on some external dependency. Creator of this class assumed that it will be serialized only in context that has connection to this dependency. Someone without broad knowledge of the system could forget about this and use this class in another context that is lacking access to it. <p>Good example of that kind of situation is accessing State of the application through the HttpContext. Our class has a property that on the get method is accessing HttpContext. I won’t see the problem if class will be used in my scenario, but later if someone will try to serialize this class in other environment that doesn’t have access to the HttpContext, a null reference exception will be thrown. It is really important to test if this kind of situation happens. To check it, I am using very simple test. <h4>Testing Serialization</h4> <p>Let’s discuss this simple test procedure.

With IJsonable interface and reflection, I can easily obtain all the types of the classes to test. Simple Linq query filters out all the classes in specified assembly, within specified namespace with defined IJsonable interface. Then for each class Activator is used to create instance of the class. Newly created object is serialized and If there is an error, name of the type is added to the list. <p>This test is using NUnit framework. Unit test runner provides perfect environment, that lacks all dependencies, so there will be errors if someone makes a class that will for example access HttpContext directly. <p>With this simple check we can almost be sure that we won’t get any stupid errors and we can easily see that something is wrong with our model. <h4>Continuous Tests</h4> <p>Running tests each time, I am making a change can become … pain in … With Resharper it is much easier, but still sometimes I will forget to do this and then beautiful message from our Jenkins server will notify me about some fail. It would be a lot better if this information would be instant. There is a solution to this called Continuous Tests. <p>I started using Mighty Moose recently. It is a plugin to Visual Studio that creates a test runner in the background. This runner analyses all the changes made in the code and on simple CTRL+S (Save) ,if it detects that recent change in the code affects tests, lined test will be executed automatically. <p>For example in serialization logic, discussed in this post, this kind of instant information can be critical. Each time I change something in the model ( some property for example ). Test is performed automatically and I will get information if this works or not. This is even better in situation when one of my colleagues is changing something inside my code. He won’t be always aware that this code is covered by unit tests, and Continuous Tests runner will notify him about this and also will inform him automatically if this change is failing tests.