Edison is designed to be a more performant unit/integration testing framework for .NET projects. Many features, such as Attributes, are similar to other test frameworks for a more fluid transition.
- 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 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.
You can now install Edison using Chocolatey using the following:
choco install edisonAlso, 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.ConsoleTo use the Edison framework and 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.
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 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
TestFixturewhich contains multipleTests to be run - A
Setupmethod which is run before eachTest - A
Teardownmethod which is run after eachTest. This can optionally take a TestResult object. - And one
Testmethod, which has aCategoryof "Name", and two possibleTestCases 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.
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 jsonThis will run the test fixtures across two 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 702Again 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 --helpThe 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: 2To 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 2For any bugs you may find or features you wish to request, please create an issue in GitHub.
Edison is completely open sourced and free under the MIT License.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent