Our Blog

Special thank you for Channel 9 and @skimedic for sharing his unit testing knowledge.

XUnit leverage some of the new features to help developers write cleaner test, as tests should be kept clean and treated as first-class citizens.

  • NUnit was not fully compatible with .NET Core 2 at the time
  • xUnit is aimed at improving test isolation and trying to codify a set of rules to establish a testing standard.
  • xUnit [Fact] and [Theory] attributes are extensible, so you can implement your own testing functionality.xUnit doesn’t use Test Lists and .vsmdi files to keep track of your tests.
  • Microsoft is using xUnit internally, one of its creators is from Microsoft. xUnit was also created by one of the original authors of NUnit.
  • Side-by-side Performance Comparison of testing frameworks can be found here https://blogs.msdn.microsoft.com/visualstudio/2017/11/16/test-experience-improvements/

Where to get it and how to add it to your projects (2 ways)

  1. Use Nuget to add xunit as well as the runner
  2. Add New Project – .NET Core xUnit Test Project

Features

  • It does work with live unit testing
  • Add [Fact] attribute on a method to mark it as a test
  • Use Theory and InlineData as mechanism to pass data into the test
  • [Theory] attribute to mark a method as a test and setup incoming parameters (2 approaches InlineData and MemberData)
  • [InlineData(1,2,3)
    • approach to pass data into the test method (add additional InlineData attributes for multiple runs of same test)
      SNAGHTML2e5cfd1e
  • MemberData(nameof(IEnumerable<object>
    • In the example below we are using a method to return data to be used (however this method could also read data from other files such as text or excel to be returned)
    • approach to pass data into the test method
      SNAGHTML2e5bc0f5
  • xUnit runs it’s tests in parallel to take advantage of today’s processors
    • tests within one class are run serial
    • tests in multiple classes are run parallel
    • can be disabled by creating a test collection (add attribute [Collection({name})], and all within the same collection will be run serial
  • in order to test that an exception is thrown
    • Assert.Throws<InvalidOperationException>(() => ThrowAnError());
      image
  • Setup/Teardown
    • There are no [Setup] and [Teardown] attributes, this is done using the test class’ constructor and an IDisposable. This encourages developers to write cleaner tests.
    • use constructor in place of Setup attributes to prepare tests
    • now use IDisposable to replace teardown i.e. public class ATestClass : IDisposable
      public void Dispose() {
         //something here to clean up
      }
  • for input/output there exists ITestOutputHelper as shown below to output log
    image

Notes

References:

https://xunit.github.io/docs/why-did-we-build-xunit-1.0.html
https://dev.to/hatsrumandcode/net-core-2-why-xunit-and-not-nunit-or-mstest--aei

https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/Unit-Testing-xUnit
https://xunit.github.io/

In Visual Studio, there are at least 3 different types of class library you can create:

  • Class Library (.NET Framework)
  • Class Library (.NET Standard)
  • Class Library (.NET Core)

* Use a .NET Standard library when you want to increase the number of apps that will be compatible with your library, and you are okay with a decrease in the .NET API surface area your library can access.

* Use a .NET Core library when you want to increase the .NET API surface area your library can access, and you are okay with allowing only .NET Core apps to be compatible with your library.

Difference:

Compatibility: Libraries that target .NET Standard will run on any .NET Standard compliant runtime, such as .NET Core, .NET Framework, Mono/Xamarin. On the other hand, libraries that target .NET Core can only run on the .NET Core runtime.

API Surface Area: .NET Standard libraries come with everything in NETStandard.Library whereas .NET Core libraries come with everything in Microsoft.NETCore.App. The latter includes approximately 20 additional libraries, some of which we can add manually to our .NET Standard library (such as System.Threading.Thread) and some of which are not compatible with the .NET Standard (such as Microsoft.NETCore.CoreCLR).

Also, .NET Core libraries specify a runtime and come with an application model. That's important, for instance, to make unit test class libraries runnable.

Ignoring libraries for a moment, the reason that .NET Standard exists is for portability; it defines a set of APIs that .NET platforms agree to implement. Any platform that implements a .NET Standard is compatible with libraries that target that .NET Standard. One of those compatible platforms is .NET Core.

Coming back to libraries, the .NET Standard library templates exist to run on multiple runtimes (at the expense of API surface area). Obversely, the .NET Core library templates exist to access more API surface area (at the expense of compatibility) and to specify a platform against which to build an executable.

Said another way…

A .Net Core Class Library is built upon the .Net Standard. If you want to implement a library that is portable to the .Net Framework, .Net Core and Xamarin, choose a .Net Standard Library

.Net Core will ultimately implement .Net Standard 2 (as will Xamarin and .Net Framework)

.Net Core, Xamarin and .Net Framework can, therefore, be identified as flavours of .Net Standard

To future-proof your applications for code sharing and reuse , you would rather implement .Net Standard libraries.

Microsoft also recommends that you use .NET Standard instead of Portable Class Libraries.

To quote MSDN as an authoritative source, .Net Standard is intended to be One Library to Rule Them All.

  1. .NET Standard solves the code sharing problem for .NET developers across all platforms by bringing all the APIs that you expect and love across the environments that you need: desktop applications, mobile apps & games, and cloud services:
  2. .NET Standard is a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation.
  3. .NET Standard 2.0 will be implemented by .NET Framework, .NET Core, and Xamarin. For .NET Core, this will add many of the existing APIs that have been requested.
  4. .NET Standard 2.0 includes a compatibility shim for .NET Framework binaries, significantly increasing the set of libraries that you can reference from your .NET Standard libraries.
  5. .NET Standard will replace Portable Class Libraries (PCLs) as the tooling story for building multi-platform .NET libraries.

References: https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/
https://stackoverflow.com/questions/42939454/what-is-the-difference-between-net-core-and-net-standard-class-library-project

About Us

Web/Mobile Solutions

Our Contacts

Cincinnati, OH 45069