Guide: Nuclear testing system

Nuclear.Test uses a three-layer testing system, that splits the process of executing tests on multiple runtimes into manageable sub problems. The result is a test platform, that allows for executing tests on multiple processor architectures and runtimes with the click of one button. The obvious advantage is feature stability of the tested code on many .NET implementations and robustness against implementation differences.

Process spawning and result data flow within the nuclear testing system.

Executor layer

A test executor is a program that receives file path information for one or more test assemblies. It handles the proxy management of all given test assemblies and receives the collected test results from all the worker processes. An executor can be anything from a PowerShell script to a Visual Studio extension. Building a custom executor can be done by relying on the ready-to-use core implementations in the core NuGet package.

Proxy layer

Proxies are small console applications and represent the second layer of the nuclear testing system. They handle the worker management of a test assembly on a specific processor architecture like x86 or x64. A proxy starts worker processes depending on the test assembly’s target framework and the current settings. The workers’ test results are forwarded to the owning executor process. Proxies usually run in the background but can also be started visible as a console application. Every proxy process will print a summary of the test scenario along with the results, as can be seen in the screenshot below.

Example of what a visible proxy process displays.

Worker layer

Workers are small console applications and represent the third layer of the nuclear testing system. Currently, there are workers available for .NETFramework (v4.6.1 – v4.8) and .NETCore (v2.0 – v5.0) each compiled for both x86 and x64. This gives a total of 24 unique workers and test scenarios. Workers scan an assembly for test methods and test classes. Test methods are executed and the results sent back to the owning proxy process. Workers usually run in the background but can also be started visible as a console application. Every worker process will print a summary of the test scenario along with the results, as can be seen in the screenshot below.

Example of what a visible worker process displays.