Unit test a format specification

I am writing a .NET CIL decompiler (just for fun). I can't figure ou开发者_开发百科t how to unit test classes in my project that do the actual 'decompiling' thing, specifically, the decoders that read a binary file & decode it to meaningful data structures. The approach I came with is to store executable files witch are subject to decoding in the same directory where my test project lies, and just read them in a test's initialization methods. There are many files, with different file format cases.

That does not really seem elegant. Would it be better to embed this files in the separate resource assembly, or even use fake objects instead, which will return the results I want for every use case? (there are a lot of use cases, so configuring such fake objects will take a lot of time, it is much easier to find executables with specific cases).

And at last, maybe decoders are not something one should unit test?

As far as I understand decoders have pretty complex logic, according to your state that there are a lot of cases in executables. So testing this code is a good idea.

As you sad we have two options for now: to have a bunch of files for the specific case and to have fake objects emulating each case. Lets review them.

Having a bunch of files vs building fake objects.

Once upon a time I've spent a huge time thinking about this problem. So lets review some cases I had in my practice and conclusions I made. I've had a strong xml parsing logic in one of my projects and I have to choose whether to store xml in xml files, in C# files as string literals or emulate each particular case I need by building XDocument objects. Last approach was killing me, but it looked like "right and elegant", then I tried to switch to C# string literals and it was also an overkill. It was very hard to edit and understand this huge strings. So I just created xml files and forget about all the problems.

In the same time in your case it seems that you don't need to edit binary files very often, but constructing of fake objects will also take a lot of time. And if there is no "cheap" possibility to fake this kind of logic I would suggest to go with files. I also do not suggest to put them in the resources, you will get no benefit for unit test projects from it.

Another argument. Why we need fake objects? We need them to fake our dependencies and isolate system under test (SUT) from everything that is not related to logic we are testing. Sometimes we have low-level layers in our applications like DB providers or decoders like in your case where using of fake objects will help to test code, but will not help to test code in real-life scenarios. And typically this is solved by covering this low-level layer with slow and comples integration tests. So in your case lets just consider that you are going to write a bunch of Integration Tests for the lowest level of your application witch is okay and elegant approach =) And after doing this you will be ready enought to abstract from this application layer and write fast and again elegant Unit Tests for the rest of you application.