fluentassertions / fluentassertions.autofac

Fluent Assertions extensions for Autofac

Extension methods to fluently assert the outcome of .NET tests

A very extensive set of extension methods that allow you to more naturally specify the expected outcome of a TDD or BDD-style unit tests. Works with .NET Standard 2.0 and higher, .NET Framework 4.7 and higher and .NET 6 and higher.

See https://www.fluentassertions.com for background information, usage documentation, an extensibility guide, support information and more tips & tricks.

Who created this?

Originally authored by Dennis Doomen with Jonas Nyrup as the productive side-kick. Notable contributions were provided by Artur Krajewski, Lukas Grützmacher and David Omid.

How do I build this?

Install Visual Studio 2022 17.8+ or JetBrains Rider 2021.3 as well as the Build Tools 2022 (including the Universal Windows Platform build tools). You will also need to have .NET Framework 4.7 SDK and .NET 8.0 SDK installed. Check global.json for the current minimum required version.

What are these Approval.Tests?

This is a special set of tests that use the Verify project to verify whether you've introduced any breaking changes in the public API of the library.

If you've verified the changes and decided they are valid, you can accept them using AcceptApiChanges.ps1 or AcceptApiChanges.sh. Alternatively, you can use the Verify Support plug-in to compare the changes and accept them right from inside Rider. See also the Contribution Guidelines.

Sponsors

     

With support from the following public sponsors

fluentassertions.autofac's Issues

Update coveralls

Hi @dennisdoomen i realized that the coveralls connection got stale after moving to the repo over to the fluentassertions github org. Any objections on granting app access?

Migrate from cake to nuke

After reading @dennisdoomen blog post 14 reasons for adopting Nuke as your next build automation tool we adopted nuke in some projects recently. So far the experience has been great and we can't think of any solid reasons to stay with Cake.

Here is some context:

• libhunt: NUKE vs Cake
• You don’t need Cake anymore; the way to build .NET projects going forward.
• 14 reasons for adopting Nuke as your next build automation tool

If you use RegisteredGeneric and Named you can't test it

Hi,

it would be nice to test if my generic registration has been successfully registered with the given name - as per following example

// PRODUCTION CODE
builder.RegisterGeneric(typeof(MyGenericTreeClass<>))
.Named("TreeImplementation", typeof(IMyGenericInterface<>))
.InstancePerDependency();

// WHAT COULD BE NICE TO HAVE AS TEST CODE
container.Should().Have().RegisteredGeneric(typeof(MyGenericTreeClass<>))
.Named("TreeImplementation", typeof(IMyGenericInterface<>))
.InstancePerDependency();

// WHAT I REALLY HAVE AS TEST CODE
container.Should().Have().RegisteredGeneric(typeof(MyGenericTreeClass<>));

Maybe am I missing something ?

Thank you very much,
Silvia

fix name clashes: Assertions should subclass ReferenceTypeAssertions

Right now, naming ShouldHave etc. deviate from standard FluentAssertions naming. Note that FluentAssertions provides base classes like ReferenceTypeAssertions<T,TAssert> for exactly these use cases.

Support for FluentAssertions 5

Using in a project already referencing FluentAssertions v5 (released 2018-02-04) trying to use fluentassertions.autofac v0.6.0 currently gives this error:

error CS0012: The type 'ReferenceTypeAssertions<,>' is defined in an assembly that is not referenced. You must add a reference to assembly 'FluentAssertions.Core, Version=4.19.2.0, Culture=neutral, PublicKeyToken=33f2691a05b67b6a'.

It would be great not having to downgrade. Any plans to upgrade this dependency?

Interceptor and parameter registrations

First of all, an awesome library, so thanks for the efforts :).

I have a question though: would it at all be possible to assert WithParameter(s) and InterceptedBy registrations? As far as I can tell it is not right now, is it? It would be an extremely useful feature for more complex scenarios with a lot of decorators etc. but I have no idea if it is doable.

Consider renaming to FluentAssertions.Ioc.Autofac

Welcome to the Fluent Assertions community extensions club!

I appreciate that you may not have the stomach for another rename, and that you have already published to NuGet.

Having said that, I run FluentAssertions.Ioc.Ninject. What you you think to renaming so that the package names are consistent? I was planning to add more FluentAssertions.Ioc.* packages, but so far haven't moved away from Ninject.

/cc @dennisdoomen

Create `RegisterSourceAssertions`

I think would be nice having a way to check if a specific RegistrationSource implementation has been registered.

One of the most common examples could be the OpenGenericRegistrationSource implementation created using the registration extension method below:

builder.RegisterGeneric(typeof(OptionsManager<>).As(typeof(IOptions<>)).SingleInstance();

Maybe something like:

container.Should().Have()
         .RegisteredSource<OpenGenericRegistrationSource>()
         .ForService(typeof(IOptions<>))
         .ImplementedBy(typeof(OptionsManager<>);

But................ OpenGenericRegistrationSource is internal :(

So, a very very raw implementation could be like below:

        ...
        GenericImplementationFor(typeof(IOptions<>), container)
                .Should()
                .Be(typeof(OptionsManager<>));
        ...

        private Type GenericImplementationFor(Type genericTypeDefinition, IContainer container)
        {
            var serviceType = genericTypeDefinition.MakeGenericType(typeof(object));
            var typedService = new TypedService(serviceType);

            var componentRegistry = container.ComponentRegistry;
            foreach (var registrationSource in componentRegistry.Sources)
            {
                var registrations = registrationSource
                    .RegistrationsFor(typedService, componentRegistry.RegistrationsFor)
                    .ToList();

                if (!registrations.Any())
                {
                    continue;
                }

                return registrations.First().Activator.LimitType.GetGenericTypeDefinition();
            }

            return null;
        }

Reference issue nuget package for FluentAssertions.Autofac 0.3.0

In the latest release, the nuspec defines a dependency for FluentAssertions 4.2.2, however the library is currently built against 4.10.0, causing VS to complain about

Assembly 'FluentAssertions.Autofac' with identity 'FluentAssertions.Autofac, Version=0.3.0.0, Culture=neutral, PublicKeyToken=null' uses 'FluentAssertions.Core, Version=4.10.0.0, Culture=neutral, PublicKeyToken=33f2691a05b67b6a' which has a higher version than referenced assembly 'FluentAssertions.Core' with identity 'FluentAssertions.Core, Version=4.2.2.0, Culture=neutral, PublicKeyToken=33f2691a05b67b6a'

Adding a referencing to FluentAssertions 4.10.0 directly causes this problem to be resolved.

Remove NUnit and NSubstitue dependencies from shipped assembly

Hey @mkoertgen!

I just tried out this package on a new project and hit a blocker - there seems to be a dependency on NUnit in the shipped assembly:

System.IO.FileLoadException : Could not load file or assembly 'nunit.framework, Version=3.0.5813.39031, Culture=neutral, PublicKeyToken=2638cd05610744eb' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
   at FluentAssertions.Autofac.ResolveAssertions`1..ctor(IContainer container)
   at FluentAssertions.Autofac.ContainerAssertions.Resolve[TService]()

I also noticed the NuGet package has a dependency on NSubstitute.

I think this is caused because you have tests alongside production code in the same project. Before I put the effort in, would you accept a PR that splits tests and production code into separate projects?

Add NotRegisterModule

It would be handy to have

builder.Should().NotRegisterModule<TModule>();

Support asserting conditional registration (OnlyIf, IfNotRegistered)

Conditional Registration was introduced in AutoFac 4.4:

• https://autofac.readthedocs.io/en/latest/register/registration.html#conditional-registration

As a developer needing to test my DI Logic i want to assert that a service is registered & resolved conditionally.

Acceptance Criteria:

• Given i conditionally registered ServiceB if ServiceA was not registered
  when i assert on X.Should().Register<ServiceB>().IfNotRegistered<ServiceA>().As<IService>()
  then the assertion passes.

Note: Is this possible? Should X be a container, builder, or module? I tend to module. Under the hood the assertion should be a shortcut to actually run 2 tests 1) register ServiceA and assert it gets resolved (not registered ServiceB) and 2) assert ServiceB gets resolved (without ServiceA).

Support cross-platform just as Autofac + FluentAssertions

Target to .net 4.7.2

Is there any change to make the nuget multitargeting and add assemblies for .net framework 4.7.2?

Or, it might be a simpler solution, make the project targeting to the latest .net framework version (4.7.2).

I have made some preliminaries tests and everything compiles and works as expected. (Unit testing in green).

Add Support for .NET 7, C# 11

Container.Should().Have() Is not found.

This one must be super simple but for whatever reason this extension method is bombing on me, as in I'm unable to compile the test project once I have included a test that uses the Have() extension.

My project is 2017 Enterprise MSTest (4.5.2) and I have been successful at using Fluent Validation in other tests in the same project.

The Should extension in the failing to compile test is of type Primitives, and when I F-12 this is returned

/// <summary>
/// Returns an <see cref="T:FluentAssertions.Primitives.ObjectAssertions" /> object that can be used to assert the
/// current <see cref="T:System.Object" />.
/// </summary>
[Pure]
public static ObjectAssertions Should(this object actualValue)
{
  return new ObjectAssertions(actualValue);
}

I believe that the Should extension should be hanging off of IContainer, right?

Any help would be appreciated.

-Stephen

Support for Autofac 6.4.0 and FluentAssertions 6.7.0

If the project being tested references Autofac 6.40 then a test project using FluentAssertions.Autofac 6.5.1 will fail.

But it just needs a redirect in the app.config:

<runtime>
	<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

		<dependentAssembly>
			<assemblyIdentity name="Autofac" publicKeyToken="17863af14b0044da" culture="neutral" />
			<bindingRedirect oldVersion="6.3.0.0" newVersion="6.4.0.0" />
		</dependentAssembly>
	</assemblyBinding>
</runtime>

So this can be closed 

Difference in resolving compared to Autofac itself

There appears to be a difference in how this package resolves components compared to Autofac itself. I have only found it in this case with multiple registrations so far. Using version 0.7.2.

[Fact]
public void Test01()
{
	var containerBuilder = new ContainerBuilder();

	// First registration.
	containerBuilder.RegisterType<MyClass>();

	// "Overriding" registration.
	containerBuilder.RegisterType<MyClass>().WithParameter("obj", new object());

	var container = containerBuilder.Build();

	// Using Autofac Resolve().
	// Test succeeds.
	var actual = container.Resolve<MyClass>();
	actual.Should().NotBeNull();

	// Using FluentAssertions.Autofac Resolve()
	// Test fails.
	container.Should().Resolve<MyClass>();
}

public class MyClass
{
	public MyClass(object obj)
	{ }
}

This is not an uncommon scenario in my experience, e.g. first registering all types by assembly scanning, and then "overriding" the ones who need extra parameters (or other special cares).

Support Autofac 6

Support for ILifetimeScope in addition to Container

The single way provided by Autofac to add new components after the container is built is by creating a new LifeTimeScope.
-> The use case is: build the container -> BeginLifetimeScope + additional registration -> test if the new registrations are in the new LifetimeScope.

Not possible to test module with constructor parameters?

The documentation states

var sut = new MyModule(...);
sut.Container(arrange: ..., types: ...)
   .Should...

sut.Builder(arrange: ..., types: ...)

Trying this code:

public class Test
{
    public void Test01()
    {
        var myModule = new MyModule(null);
        myModule.Container().Should().Resolve<object>();
    }

    public class MyModule : Autofac.Module
    {
        public MyModule(object obj)
        { }
    }
}

Gives compilation error
error CS0310: 'Test.MyModule' must be a non-abstract type with a public parameterless constructor in order to use it as parameter 'TModule' in the generic type or method 'TestExtensions.Container<TModule>(TModule, Action<ContainerBuilder>)'

which is expected given the generic new() constaint of the method TestExtensions.Container(...).

Did I misread the documentation? If not, is it still possible to test a module with constructor parameters?

Support of .net core

Please consider supporting .net core also. Right now I get the following exception, when trying to use FluentAssertion.Autofac with a .net core application:

  Package FluentAssertions.Autofac 0.3.2 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package FluentAssertions.Autofac 0.3.2 supports: net45 (.NETFramework,Version=v4.5)
  One or more packages are incompatible with .NETCoreApp,Version=v1.0.

Wrong dependency version?

1. Create a new .net 461 class library.
2. Install package FluentAssertions.Autofac 0.7.1
3. Add code

using Autofac;
using FluentAssertions.Autofac;

public class Test
{
    public void Test01() => new ContainerBuilder().Build().Should().Resolve<object>();
}

4. Compile

Compilation fails with error
error CS1705: Assembly 'FluentAssertions.Autofac' with identity 'FluentAssertions.Autofac, Version=0.7.1.0, Culture=neutral, PublicKeyToken=null' uses 'FluentAssertions, Version=5.1.2.0, Culture=neutral, PublicKeyToken=33f2691a05b67b6a' which has a higher version than referenced assembly 'FluentAssertions' with identity 'FluentAssertions, Version=5.0.0.0, Culture=neutral, PublicKeyToken=33f2691a05b67b6a'

It seems the project is referencing 5.1.2
<Reference Include="FluentAssertions, Version=5.1.2.0, Culture=neutral, PublicKeyToken=33f2691a05b67b6a, processorArchitecture=MSIL"> <HintPath>..\packages\FluentAssertions.5.1.2\lib\net45\FluentAssertions.dll</HintPath> </Reference>

While the nuspec only requires 5.0.0:
<dependency id="FluentAssertions" version="[5.0.0, 6.0.0)" />.

Strong-name sign so that delay-signed projects can be executed.

System.IO.FileLoadException
Could not load file or assembly 'FluentAssertions.Autofac, Version=0.7.2.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)
at My.ComponentTests.Lib.ShouldFooBar()

Documentation speaks about NInject

On this page https://github.com/fluentassertions/fluentassertions.autofac/blob/develop/README.md
the Why? paragraph speaks about NInject, not Autofac.

Support for Decorators

As a developer needing to test my DI Logic i want to assert that a decorator wrapping a service is registered & will be resolved.

Acceptance Criteria:

• Given i registered a service decorator
  when i assert on the container registrity container.Should().Have().RegisteredDecorator<TDecorator, IDecoratedService>()
  then the assertion passes

Idioms:

• RegisterDecorator()
• RegisterGenericDecorator()

Enhancements introduced in 4.9, cf.: https://alexmg.com/posts/upcoming-decorator-enhancements-in-autofac-4-9

• builder.RegisterDecorator<DecoratorA, IDecoratedService>();
  builder.RegisterDecorator<DecoratorB, IDecoratedService>(); // Will be applied last.
• builder.RegisterDecorator(typeof(DecoratorA), typeof(IDecoratedService));

Other references:

• https://hackernoon.com/apply-the-decorator-pattern-in-net-using-autofac-957502b771f7