Description

When an event handler accessor has an explicit implementation, which throws an exception on the setter, .Monitor() is failing the test completely.

What is my motivation?

I need to test the class behavior without changing the other base event handler accessors behavior. It could cause unwanted side effects. But I do not need to test this event. I just wanted to test PropertyChanged events being raised. Therefore, I would like to have the benefit of having the full class available to write expressions in the assertion.

Suggestion:

Make some more configuration options for the Monitor. Like ignoring failing events, or just subscribing to a subset of interfaces with those events, or putting some events on ignore, without changing the generic Type, which is used to assert / monitor.

Benefit:

Using the great syntax you introduced in monitor on brown field projects or if you are not able to change the behavior of some event accessors. Therefore, write better and cleaner test code from the beginning.

Complete minimal example reproducing the issue

using System.ComponentModel;
using Xunit;

namespace FluentAssertions.Tests;

class FailingEventHandlerSubscription : INotifyPropertyChanged
{
    private event PropertyChangedEventHandler? InnerPropertyChanged;
    public event PropertyChangedEventHandler? PropertyChanged
    {
        add { throw new System.Exception("This is sadly happening due to anonymous method"); }
        remove { InnerPropertyChanged -= value; }
    }

    private object prop;

    public object Property
    {
        get => prop;
        set
        {
            prop = value;
            this.InnerPropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(Property)));
        }
    }
}

public class UnitTest2
{
    [Fact]
    public void TestEventHandler()
    {
        // Arrange
        var cut = new FailingEventHandlerSubscription();

       // will fail, because the exception is thrown, when the EventHandler class is subscribing the event.
        using var monitored = cut.Monitor();

        // Act
        cut.Property = new object();

        // Assert
        // If I just use the INotifyPropertyChanged interface, I cannot write this awesome expression.
        monitored.Should().RaisePropertyChangeFor(m => m.Property);
    }
}

Expected behavior:

FluentAssertions is able to have options in the monitor to ignore failing event handlers.

Actual behavior:

It throws an exception when .Monitor() is called and I can do nothing about it, event though I do not want to test this specific event.

Versions

FluentAssertions Version 6.7.0

Additional Information

I already implemented my custom implementation of the monitor and would offer to contribute my suggestion above to the FluentAssertions project. I just wanted to talk to you first, if you would approve of such an enhancement of the monitor or if you disagree on this feature for some reason.

So let me know if you agree or disagree.

cheers!