Unit test tools comparison

Today we will take a look into a few popular C unit testing frameworks and try them out first hand so you can choose which one best suits your project. Popular Automated Unit Testing Frameworks. All of these unit testing frameworks offer a similar end goal, to help make writing unit tests faster, simpler and easier! But there are still a few key differences between them. Some are more focused towards powerful complex tests, while others rank simplicity and usability as a higher priority.

Code coverage tools. You can determine the amount of product code that your unit tests exercise from one command in Test Explorer.

MSTest has been around since Visual Studio , at least. For this reason, a lot of people opted to use NUnit instead. Since V2 MSTest also supports parameters, so the difference between the frameworks on a day-to-day basis has lessened a lot.

A very basic test class using MSTest will look like this:. NET Framework. Written by the original inventor of NUnit v2, xUnit.

NET and other. NET languages. NET and Xamarin. Setting extra properties on models or using non-zero values when not required, only detracts from what you are trying to prove.

Naming variables in unit tests is as important, if not more important, than naming variables in production code. Unit tests should not contain magic strings. Magic strings can cause confusion to the reader of your tests. If a string looks out of the ordinary, they may wonder why a certain value was chosen for a parameter or return value. This may lead them to take a closer look at the implementation details, rather than focus on the test. When writing tests, you should aim to express as much intent as possible.

In the case of magic strings, a good approach is to assign these values to constants. When writing your unit tests avoid manual string concatenation and logical conditions such as if , while , for , switch , etc. When you introduce logic into your test suite, the chance of introducing a bug into it increases dramatically. The last place that you want to find a bug is within your test suite.

You should have a high level of confidence that your tests work, otherwise, you will not trust them. Tests that you do not trust, do not provide any value. When a test fails, you want to have a sense that something is actually wrong with your code and that it cannot be ignored. If logic in your test seems unavoidable, consider splitting the test up into two or more different tests. If you require a similar object or state for your tests, prefer a helper method than leveraging Setup and Teardown attributes if they exist.

In unit testing frameworks, Setup is called before each and every unit test within your test suite. While some may see this as a useful tool, it generally ends up leading to bloated and hard to read tests. Each test will generally have different requirements in order to get the test up and running. Unfortunately, Setup forces you to use the exact same requirements for each test. When writing your tests, try to only include one Act per test.

Common approaches to using only one act include:. Multiple Acts need to be individually Asserted and it is not guaranteed that all of the Asserts will be executed.

In most unit testing frameworks, once an Assert fails in a unit test, the proceeding tests are automatically considered to be failing. This can be confusing as functionality that is actually working, will be shown as failing. In most cases, there should not be a need to test a private method. Private methods are an implementation detail. You can think of it this way: private methods never exist in isolation. At some point, there is going to be a public facing method that calls the private method as part of its implementation.

What you should care about is the end result of the public method that calls into the private one. Your first reaction may be to start writing a test for TrimInput because you want to make sure that the method is working as expected. However, it is entirely possible that ParseLogLine manipulates sanitizedInput in such a way that you do not expect, rendering a test against TrimInput useless.

The real test should be done against the public facing method ParseLogLine because that is what you should ultimately care about. With this viewpoint, if you see a private method, find the public method and write your tests against that method.

Just because a private method returns the expected result, does not mean the system that eventually calls the private method uses the result correctly. One of the principles of a unit test is that it must have full control of the system under test. This can be problematic when production code includes calls to static references for example, DateTime. Consider the following code. To solve these problems, you'll need to introduce a seam into your production code.

One approach is to wrap the code that you need to control in an interface and have the production code depend on that interface. Now the test suite has full control over DateTime. Now and can stub any value when calling into the method.

Skip to main content. For a larger list, see the list on wikipedia. We admit it, we're somewhat biased. But we'll try to stick to the facts. Unity has a number of features that make it stand out.

Google Test is a reliable and quickly growing option. It seems to have great support, is well thought out, and is feature rich. It has some nice features like fixtures, rudimentary memory leak detection, and mocking.

CHECK is a framework which focuses on ease-of-use. It's intended for unix C developers, though it supports Windows people too if they're willing to install MinGW or Cygwin. They keep it intentionally small to keep it easier to learn, but this doesn't lend itself well to Embedded Developers.