Edison

Edison is designed to be a more performant and feature rich unit/integration testing framework for .NET projects. Many features, such as Attributes, are similar to other test frameworks for a more fluid transition.

Features

• Framework with Attributes and Assert class for writing unit/integration tests.
• Can run tests in parallel.
• Output can be in XML, JSON, CSV, HTML, Markdown or just plain text.
• Ability to send test results, in real-time, to a URL for later analysis.
• Console application from which to run your tests.
• GUI for a more visual look on running tests.
• Ability to re-run tests that have failed, for ones that may pass if run seconds later.
• Run test cases and repeats in parallel.
• Supply a .NET solution file for extracting test assemblies.
• Ability to store versioned console parameters in an Edisonfile.
• Basic support for browser testing.
• Support for TestDriven.NET.
• Send test results to specific Slack channels, or to users directly.

Installing Edison

You can now install Edison using Chocolatey using the following:

choco install edison

Also, you can now get the framework and console on NuGet as well:

Install-Package Edison.Framework
Install-Package Edison.TestDriven # < this is the core framework, but has support for TestDriven.NET
Install-Package Edison.Console

To use the Edison framework with TestDriven.NET, you'll need to install the second package above. Then you'll need to manually add a reference to the Edison.Framework.dll within the Edison.TestDriven\tools directory of the project's nuget packages directory.

Usage

Framework

Using Edison is very similar to other test frameworks. You have a [Test] Attribute with varying other Attributes to create your tests. An example would be:

[TestFixture]
public class TestClass
{
    [Setup]
    public void Setup()
    {
        //stuff
    }

    [Teardown]
    public void Teardown(TestResult result)
    {
        //stuff
    }

    [Test]
    [Category("Name")]
    [TestCase(1)]
    [TestCase(2)]
    public void Test(int value)
    {
        AssertFactory.Instance.AreEqual(2, value, "Argh no it's an error!!!1");
    }
}

Here you can see that this is mostly very similar to other test frameworks. Edison has been designed this way to make it easier for people to transition over.

In the example above we have:

• A TestFixture which contains multiple Tests to be run
• A Setup method which is run before each Test
• A Teardown method which is run after each Test. This can optionally take a TestResult object.
• And one Test method, which has a Category of "Name", and two possible TestCases to run the Test with as 1 and 2.

Furthermore, there's the Asserts class. In Edison the main Assert class implements the IAssert interface. To use the Assert class you can either create an instance of it for each Test, or you can use the AssertFactory class. The AssertFactory class contains a lazy Instance property which returns the IAssert class being used for the test assembly. This means you can create your own CustomAssert class that inherits IAssert and do AssertFactory.Instance = new CustomAssert() and any calls to AssertFactory.Instance will return your CustomAssert. This makes it far simpler to have your own assert logic in your test framework. If you don't set the AssertFactory.Instance then this is default to be the inbuilt Assert logic.

Console and Engine

Edison has the inbuilt functionality to run tests in parallel threads. By default tests are run in a single thread however, by suppling the -t <value> parameter from the command-line the tests will be run in that many threads. If you supply a number of threads that exceeds the number of TestFixtures, then the number of threads will become the number of TestFixtures.

Edison has the following flow when running tests per assembly:

SetupFixture -> Setup
 |
TestFixture -> TestFixtureSetup
 |
TestFixture -> Setup
 |
TestFixture -> Tests and TestCases
 |
TestFixture -> Teardown
 |
TestFixture -> TestFixtureTeardown
 |
SetupFixture -> Teardown

Example of running a test assembly from the command-line:

.\Edison.Console.exe --a path/to/test/assembly.dll --ft 2 --ot json

This will run the tests across two fixture threads (--ft) from the assembly.dll file (--a). The results of the tests will be output to the working directory in json format (--ot).

Do you have your own in-house test history storage? You can post the test results from Edison.Console to a given URL. Also you can specify a Test Run ID to help uniquely identify the run the results came from:

.\Edison.Console.exe --a path/to/test/assembly.dll --ft 2 --dfo --dco --ot json --url http://someurl.com --tid 702

Again this will run the test fixtures across two threads however, this time we won't be creating an output file (--dfo) or outputting the results to the console (--dco). Instead, the results will be posted to the passed URL (--url) and also use the test run ID specified (--tid).

To see more parameters use:

.\Edison.Console.exe --help

Edisonfile

The Edisonfile allows you to save, and version control, the arguments that you can supply to the console application. The file is of YAML format and should be saved at the root of your repository.

The following is an example of the format:

assemblies:
  - "./path/to/test.dll"
  - "./path/to/other/test.dll"

disable_test_output: true
console_output_type: dot
fixture_threads: 2

To run the application, just run Edison.Console.exe at the root, with no arguments supplied. The application will locate the Edisonfile and populate the parameters accordingly.

For example, the above will be just like running:

Edison.Console.exe --a ./path/to/test.dll, ./path/to/other/test.dll --dto --cot dot --ft 2