A fluent API for .Net Standard that can enforce architectural rules in unit tests and create a self-testing architecture. Inspired by the ArchUnit library for Java.
NetArchTest is a well-established mature library, but to push things forward, a few breaking changes had to be made, and that is how eNhancedEdition was born. eNhancedEdition uses almost identical Fluent API as a base library, but it is not 100% backwards compatible, and it will never be.
What eNhancedEdition has to offer, that is not available in the NetArchTest v1.3.2:
fixed all known bugs present in v1.3.2 :
BenMorris/NetArchTest#98,
BenMorris/NetArchTest#101,
BenMorris/NetArchTest#120,
NeVeSpl/NetArchTest.eNhancedEdition#3
corrected design mistakes:
BenMorris/NetArchTest#119 - fixed nulls for Success result
BenMorris/NetArchTest#130 - for generic type, number of type parameters (e.g. `1) is no longer considered as a part of its name
BenMorris/NetArchTest#105 - dependency search functions: HaveDependencyOnAny/OnlyHaveDependencyOn explain why a type fails test through IType.Explanation
BenMorris/NetArchTest#126 - added rules for structs, enums and delegates
BenMorris/NetArchTest#131 - added rules for all access modifiers: public, internal, private, protected, private protected, protected internal
Finally, you obtain a result from the rule by using an executor, i.e. use GetTypes() to return the types that match the rule or GetResult() to determine whether the rule has been met.
Note that GetResult() returns TestResult which contains a few lists of types:
SelectedTypesForTesting - types that passed predicates
FailingTypes- types that failed to meet the conditions
var result = types.That().ResideInNamespace("MyProject.Data").Should().BeSealed().GetResult();
var isValid = result.IsSuccessful;
var types = result.FailingTypes;
Tip
Loading types is time-consuming, since Type class is immutable, its instance can be shared between tests.
Rules for dependency analysis
Dependency matrix:
type\has dependency on
D1
D2
D3
a
b
x
c
x
d
x
x
e
x
f
x
x
g
x
x
h
x
x
x
Dependency search:
Rule
number<br> of required<br> dependencies <br>from the list
type can have<br>a dependency<br>that is not<br>on the list
Rules for assessing design and architectural principles
BeImmutable
A Type is considered as immutable when all its state (instance and static, fields, properties and events) cannot be changed after creation. Shallow immutability.
BeImmutableExternally
A Type is considered as externally immutable when its state (instance and static, fields, properties and events) with a public access modifier cannot be changed from the outside of the type. Shallow immutability.
BeStateless
A Type is considered as stateless when it does not have an instance state (fields, properties and events).
BeStaticless
A Type is considered as stateless when it does not have a static state.
HaveParameterlessConstructor
A type should have a parameterless instance constructor.
DoNotHavePublicConstructor
A type should not have any instance public constructors.
HaveSourceFileNameMatchingName
HaveSourceFilePathMatchingNamespace
HaveMatchingTypeWithName
Slices
var result = Types.InAssembly(typeof(ExampleDependency).Assembly)
.Slice()
.ByNamespacePrefix("MyApp.Features")
.Should()
.NotHaveDependenciesBetweenSlices()
.GetResult();
There is only one way, at least for now, to divide types into slices ByNamespacePrefix(string prefix) and it works as follows:
Select types which namespace starts with a given prefix, rest of the types are ignored.
Slices are defined by the first part of the namespace that comes right after the prefix:
namespacePrefix.(sliceName).restOfNamespace
Types with the same sliceName part will be placed in the same slice. If sliceName is empty for a given type, the type will also be ignored (BaseFeature class from the following image)
When our types are divided into slices, we can apply the condition: NotHaveDependenciesBetweenSlices(). As the name suggests it detects if any dependency exists between slices. Dependency from slice to type that is not part of any other slice is allowed.
passing
failing
Custom rules
You can extend the library by writing custom rules that implement the ICustomRule interface. These can be applied as both predicates and conditions using a MeetsCustomRule() method, e.g.
var myRule = new CustomRule();
// Write your own custom rules that can be used as both predicates and conditions
var result = Types.InCurrentDomain()
.That()
.AreClasses()
.Should()
.MeetCustomRule(myRule)
.GetResult()
.IsSuccessful;
Options
User Options allows to configure how NetArchTest engine works.
var result = Types.InCurrentDomain()
.That()
.ResideInNamespace("NetArchTest.TestStructure.NameMatching.Namespace3")
.Should()
.HaveNameStartingWith("Some")
.GetResult(Options.Default with { Comparer = StringComparison.Ordinal});
Assert.True(result.IsSuccessful);
Available options:
Comparer - allows to specify how strings will be compared, default: InvariantCultureIgnoreCase (it only affects: Predicate.HaveName, Predicate.HaveNameStartingWith, Predicate.HaveNameEndingWith, Predicate.ResideInNamespace)
SerachForDependencyInFieldConstant - determines if dependency analysis should look for dependency in string field constant, default: false
Limitations
NetArchTest is built on top of jbevain/cecil thus it works on CIL level. Unfortunately, not every feature of C# language is represented in CIL, thus some things will never be available in NetArchTest, e.g.:
BenMorris/NetArchTest#81 - NetArchTest ignores a nameof expression
