Standardizing unit testing across Tenacom projects

[ric15ni]

As evidenced in #10, we need to settle on a standard for unit testing and coverage, including:

• a set of libraries and tools;
• standard naming for test projects, classes, and methods;
• guidelines for writing tests.

This discussion is meant as both an ongoing research report, and a seed for a test style guide to add to our Contributor guide.

I'm focusing on unit testing in this discussion, as software testing in general is too broad a topic; besides, we already do our share of (admittedly non-standardized) acceptance- and smoke-testing already.

Unit tests are the kind of tests closest to the source code and the easiest to automate. Let's start from here, we can add integration and functional testing once we're done.

[ric15ni]

Requirements

• Clean assertion syntax
• Helpful messages from failing tests
• Latest Visual Studio support
• dotnet test support
• Multi-platform (Windows, Linux, Mac)
• Support for all currently MS-supported frameworks (.NET Framework 4.62+, .NET Core 3.1, .NET 6)
• Support for .NET 7 present or incoming
• Coverage reports
• Support for both synchronous and asynchronous tests
• Support for test cases (single test, multiple data sets)
• Free to use, at least for OSS projects

Unit testing framework

I think xUnit.net would be our best choice, with NUnit a close second. The former helps write cleaner code, the latter is better documented.

A NUnit feature that I'd miss in xUnit.net would be platform-specific tests that are automatically executed or skipped based on runtime OS. But we can use SkippableFact: not as terse as NUnit's [Platform] attribute, but more flexible as it lets you dynamically skip tests based on any condition.

Fluent test syntax

Regardless of the final choice between xUnit.net and NUnit, I strongly suggest adding a library that implements fluent test syntax.

I personally recommend FluentAssertions, with Shouldly, and NFluent ex-aequo seconds.

[rdeago]

OK, let's try writing unit tests for AaaLib using xUnit.net and FluentAssertions.

In the meanwhile we can (and must):

• start thinking about naming;
• find out how to produce and consume coverage reports.

[ric15ni]

I'm preparing a PR to close #10 and there's one thing we forgot: what do we do with collected coverage data?

There's already a Tenacom project using Codecov. @rdeago is it a company standard, or should I research alternatives?

[rdeago]

Codecov FTW 👍 It's already set up for the organization, just use their action to upload data and enjoy.

Look in their docs for the badge to put in README. 😉