BenMorris / NetArchTest

A fluent API for .Net that can enforce architectural rules in unit tests.
MIT License
1.36k stars 81 forks source link

Highlighting "why" a type fails test #105

Closed brettpostin closed 1 year ago

brettpostin commented 1 year ago

In my tests I am outputting the types that fail the test. However what would be great is to identify the reason why that type fails the test.

e.g.

var result = Types.InAssembly(typeof(Foo).Assembly)
    .Should()
    .OnlyHaveDependenciesOn(new string[] { "Bar" })
    .GetResult();

Assert.True(result.IsSuccessful, GetFailingTypes(result));

It would be great to see the dependencies causing the violation. Is there any means to do that at present?

BenMorris commented 1 year ago

I'm afraid not - the whole execution chain is predicated on building up a list of types that pass or fail rules (see FunctionSequence.Execute()). It doesn't retain any other metadata around why a rule failed for each type.

thomaseyde commented 1 year ago

How can I vote for this as a feature request? I have struggled for two hour now to figure out why two simple types of mine fail.

NeVeSpl commented 1 year ago

Implementing that would require too many breaking changes, including performance profile/impact, thus I do not think that this will be ever implemented here. I have started the parallel project, that allows sending metadata alongside the type, and I have in mind this issue, but right now I do not have the motivation to push it forward.

thomaseyde commented 1 year ago

Fair enough. Thank you for the response 🙂

Mvh Thomas Eyde

On 8 Nov 2022, at 14:04, NeVeS @.***> wrote:

 Implementing that would require too many breaking changes, including performance profile/impact, thus I do not think that this will be ever implemented here. I have started the parallel project, that allows sending metadata alongside the type, and I have in mind this issue, but right now I do not have the motivation to push it forward.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

brettpostin commented 1 year ago

@thomaseyde we switched to ArchUnitNET, which according to nuget uses this project as a dependency and does report on failure reasons.