Extensibility example of unit test framework nunit

First, define a custom attribute.

Using system; namespace nunit. core. extensions {// <summary> // This custom feature is only used to mark classes, nunit finds that the labeled class will call the logic of our plug-in to construct the test class // </Summary> [attributeusage (attributetargets. class, allowmultiple = false)] public sealed class samplefixtureextensionattribute: attribute {}}

The main logic of a plug-in is as follows:

Using system; using nunit. core. builders; using nunit. core. extensibility; namespace nunit. core. extensions {// The nunitaddin feature [nunitaddin (description = "this plug-in encapsulates nunittestfixture and changes the logic of setup and teardown. ")] Public class samplefixtureextensionbuilder: isuitebuilder, iaddin {# region isuitebuilder memberspublic bool canbuildfrom (type) {return reflect. hasattribute (type, "nunit. core. extensions. samplefixtureextensionattribute ", false);} public test buildfrom (type) {If (canbuildfrom (type) {return New samplefixtureextension (type);} return NULL ;} # endregion # region iaddin memberspublic bool install (iextensionhost host) {iextensionpoint suitebuilders = host. getextensionpoint ("suitebuilders"); If (suitebuilders = NULL) return false; suitebuilders. install (this); Return true ;}# endregion }}

We can see that this plug-in implements the isuitebuilder interface, which is an extension of the suitebuilder extension point. The main function of the extension point is to build a test class from the class. When nunit is started, it will scan the addins directory, load all the assembly, and scan all the public classes. If nunitaddin is implemented, it will store this type into an array. When the core is initialized, the extension points and built-in extensions are loaded first, and then the previous array is traversed to construct the instance of this class. Our example is the samplefixtureextensionbuilder class, to iaddin, call install and pass the current host as a parameter. As described above, the extended Host implements the iextensionhost interface. In our install method, we use its getextensionpoint method to obtain the extension point object. In this example, we obtain suitebuilders and the extension point, they implement the iextensionpoint or iextensionpoint2 interface, call the install method of the extension point object, and pass in the extension itself. The install method of all extension points is inherited from the extensionpoint. Therefore, the install method logic of all extension points is the same, except that the template mode is used here, will call the inspection of each extension Point class, is it suitable for expansion, and then added the extension set.

These are not enough. What test classes do we want to build with the custom samplefixtureextensionattribute class?

Using system; namespace nunit. core. extensions {/// <summary> /// this class inherits from nunittestfixture and overwrites extensible Methods /// </Summary> class samplefixtureextension: nunittestfixture {public samplefixtureextension (type fixturetype): Base (fixturetype) {// you do not need to do anything here, because we have used the construction of the base class} // below we have rewritten the method of the base class protected override void doonetimesetup (testresult suiteresult) {console. writeline ("extended fixture setup called"); base. doonetimesetup (suiteresult);} protected override void doonetimeteardown (testresult suiteresult) {base. doonetimeteardown (suiteresult); console. writeline ("extended fixture teardown called ");}}}

Okay. Now let's take a look at the buildfrom method in the isuitebuilder member in our extension. It will construct the qualified class into a class of samplefixtureextension type, so how can we build it, we call the construction method of the base class nunittestfixture.

Next, create a test project to reference the DLL generated by our plug-in project and create a test class to test our plug-in.

using System;using NUnit.Framework;using NUnit.Core.Extensions;namespace NUnit.Extensions.Tests{/// <summary>/// Test class that demonstrates SampleFixtureExtension/// </summary>[SampleFixtureExtension]public class SampleFixtureExtensionTests{[TestFixtureSetUp]public void SetUpTests(){Console.WriteLine( "TestFixtureSetUp called" );}[TestFixtureTearDown]public void FixtureTearDown(){Console.WriteLine( "TestFixtureTearDown called" );}[Test]public void SomeTest(){            Assert.IsEmpty("");}[Test]public void AnotherTest(){            Assert.IsNaN(5d);}}}

Compile the test project.

 

Copy the compiled DLL file to the addinsdirectory of the nunitinstallation directory and run nunit.exe. Click addin In the Tools menu. We can see the plug-in list. here we can see our plug-ins. Then add your test project and run it. On the output text output tab, you can see:

Extended fixture setup called
Testfixturesetup called
Testfixtureteardown called
Extended fixture teardown called

We can see that our plug-in is working normally, and we add new behaviors that nunit itself does not have, so the plug-in's goal is achieved.

 

However, why are the other two common test methods not running? You can take a look at the nunit Interface Test tree, there is no node for these two methods at all? We know that the test class we built inherits from nunittestfixture, And the constructor of this class only processes the methods marked as setup and teardown. Therefore, the other two common methods are not constructed at all, therefore, the test tree does not have the nodes of the two methods, let alone the running.

 

If

What if we remove the samplefixtureextension mark from the test class?

After the tool is removed, recompile it. Let's see the test tree on the interface. The nodes sometest and anothertest have already appeared. From this, we can know that nunit monitors the DLL of the test project. When it changes, A test is built. At this time, this test class is only a flexible test class, and these two methods are also built. Run, result ??

There is an error. On the errors or failures tab, we get the following information:

Nunit. Extensions. Tests. samplefixtureextensiontests. anothertest:
Expected: Nan
But was: 5.0d

This assertion fails, which is exactly what we want to achieve.

On the text output tab, the following information is displayed:

Testfixturesetup called
* *** Nunit. Extensions. Tests. samplefixtureextensiontests. sometest
Testfixtureteardown called

This is the simplest test behavior.

 

Conclusion