xUnit Extensions

[farlee2121]

Figure out how to replicate my unit/integration extension to nUnit with xUnit.

Also, instead (or in addition to?) adding to the test name, I can add traits to organize the test more hierarchically

http://www.brendanconnolly.net/organizing-tests-with-xunit-traits/

[farlee2121]

test name automation https://bitwiseguy.wordpress.com/2015/11/23/creating-readable-xunit-test-method-names-automatically/

Not very relevant anymore, these token replacements

[farlee2121]

Official set of extension examples https://github.com/xunit/samples.xunit

Deep equals and assertion extension https://stackoverflow.com/questions/16194952/extending-xunit-assert-class-with-new-asserts

Samples of extensions https://xunit.net/docs/upgrade-extensions

Extensiblity examples in an old version of xunit https://www.bricelam.net/2012/04/xunitnet-extensibility.html

[farlee2121]

XUnit offers some default naming configuration through the xUnit config file

https://xunit.net/schema/current/xunit.runner.schema.json https://xunit.net/docs/configuring-with-json

[farlee2121]

If collection fixtures don't work, I may be able to implement integration/unit test reuse by making inherited theory/fact attributes

https://codopia.wordpress.com/2017/02/20/xunit-net-vs-nunit-a-pragmatic-comparison/

[farlee2121]

Needs more research, but there is the IUseFixture that allows you to define a method for setting up that fixture. Maybe I implement different test run strategies as variants of this and have a setup method for each run strategy.

[farlee2121]

Summary of findings, the samples repository (https://github.com/xunit/samples.xunit) is really the definitive source of extension documentation. You can override most any step, this example shows an example of overriding almost every step

DisplayNames: Looks like display names could be overwritten by make a new TestCase type or TestCaseRunner
Integration/Unit Reuse:

• Could do it at the theory level, but i'd have to set configuration in every test method
• Can use Activator.CreateInstance(testClass.Class.ToRuntimeType()) starting at the CollectionRunner (and down) to create an instance of the test class. Could then modify properties on the test class to run different configurations

Points of extension

• Fact/Theory inheritance:
• Class/Collection/Assembly fixture: share data between tests, breaks test isolation and not conditional
• TestDiscover: Manage how tests are discovered, i.e. find only certain attributes, look for additional attributes, etc
• TestRunner:
• TestInvoker
• TestOrder: ITestCaseOrderer to order tests. could probably insert tests here too
• Assertions: can write extensions for custom assertions
• Traits: can inherit from traits to create attributes for repeated trait usage

xUnit Flow: Discoverer > Executor > AssemblyRunner > CollectionRunner > TestClassRunner > TestMethodRunner > TestCase > TestCaseRunner > TestRunner > TestInvoker