error message improvement

[wolframhaussig]

I created a test library with a simple single class:

    public class Class1
    {
        private static object LOCK_OBJECT = new object();
    }

My tests look like this:

    [TestClass]
    public class UnitTest1
    {
        internal static readonly ArchUnitNET.Domain.Architecture ARCHITECTURE = new ArchLoader().LoadAssemblies(
                                            typeof(Class1).Assembly).Build();
        [TestMethod]
        public void TestMethod1()
        {
            Types()
                .That().ResideInNamespace("ClassLibrary1")
                .Should().OnlyDependOn(
                    Types().That().ResideInAssembly("System")
                    )
                .Check(ARCHITECTURE);
        }
    }

This test complains about:

Assert.Fail failed. "Types that reside in namespace with full name "ClassLibrary1" should only depend on Types that reside in assembly with full name "System"" failed: ClassLibrary1.Class1 does depend on System.Object and System.Runtime.CompilerServices.NullableAttribute and ClassLibrary1.Class1

Note that it also complains about system types. When I add .Or().ResideInNamespace("ClassLibrary1"), the test succeeds.

Is it possible to only complain about types that real errors instead of complaining about all references? Or am I missing something?

[drewburlingame]

I've found this annoying as well. The actual errors appear at the end of the message but it's easy to miss this with all the noise.

[alexanderlinne]

Hello @wolframhaussig,

thank you for reporting this issue.

I've now been investigating this and found the following:

• If you want to match Types from System Namespace you would need to do Types().That().ResideInNamespace("^System.*", true). On the one hand, these types are distributed among multiple namespaces and assemblies. On the other hand, ResideInAssembly currently matches the fully qualified name of the assembly, which not only includes it's name. We plan to change this in the future, I've created #290 to track this separately.
• That the type itself is included does not make much sense in my opinion. Given that usually most types have some dependency on themselves I'm preparing a patch that filters these dependencies.
• That is System types are listed in the error is actually a bug in how the errors are formatted. I'm also working on a patch for this.

I will link this issue as soon as the patch is ready.