What's the best kind of test for complex calculations without access to external resources?

Question

I have two libraries that handle the mapping from one family of objects to another one. I had to create a middle set of objects for other transformations.

So, the NativeConverters libray converts elements NativeElement to MiddleElement, and the ViewModelConverters library converts MiddleElement to ViewModelElements.

I have unit tests (with NUnit) for both NativeConverters and ViewModelConverters. So the single conversion works well.

Now, I want to test the whole process: given a converter from NativeConverters and another one from ViewModelConverters, I want to test that a NativeElement gets converted correctly into a ViewModelElement.

I don't need access to DB, file system or whaterver, so I'm not sure that Integration tests are the best choice. But I'm not testing a single method, so it shouldn't be a unit test.

What kind of test do you think could best fit this case?
Do you know any library for C#?

Answer 1

But I'm not testing a single method, so it shouldn't be a unit test.

This is a misunderstanding of what a unit test is. A "unit of code" makes no sense as a measure of a test, for what is a unit of code? A class? A method? A single statement? A single CPU operation? Instead, a unit test should be seen as a test a unit of execution, ie a piece of code that can run in isolation without side effects. Effectively, if you can run two automated tests at the same time without them affecting each other, then they are unit tests.

The way you describe the full conversion process, this falls into the category of a unit of execution. Therefore tests of that full process are unit tests.

Alternatively, don't get hung up on terms "unit" and "integration". Just write automated tests. Some will be side effect free and will need no mocking. Some will need mocks to avoid brittle side effects. But they are all automated tests.

Do you know any library for C#?

NUnit can be used to write integration tests as well as unit tests. So stick with what you are already using.