Search code examples
c#unit-testingtestingcompressiontestcase

How to write unit tests for methods that compress and decompress?


I need to write unit tests for methods that compress and decompress an ArraySegment object. There are plenty of strange treatments inside these methods which I do not need to understand. (They also use some system methods — I don't know their implementation.)

The problem lies in how to actually test such things. I could check what the result is for the compression method for concrete input — Lorem ipsum dolor sit amet, consectetur adipisicing elit. — and create a test case based on this experiment, but this solution doesn't test any border cases.

I could also test whether doing compression and then decompression on some sequence gives me the first input sequence, but that would not be a pure unit test.

Have you ever come across such a problem? Is there any good solution for it?


Solution

  • I find myself writing tests like this periodically. Writing tests for code that wraps encryption works similarly.

    You can't mock or stub code that you don't fully understand (i.e. code whose results you can't predict exactly), so don't worry aboout writing pure unit tests.

    • Yes, test that compressing and decompressing gives you back the input.
    • Test that compressing the input produces output that is smaller than the input.
    • If there are any nuances of the compression algorithm that are important to your program, such as that it compresses a particular input to a particular degree, you can test that. The main value here is documenting that the library you use has these properties and that you care.
    • Test edge cases such as zero length and very long input.
    • I would not test that compressing a particular input produces a particular output, because that might break if you upgraded the compression library to a version that does a better job of compressing. However, if you need to persist compressed data and uncompress it later, do test that the compressed version doesn't change so you don't upgrade the library and orphan persisted data.