question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Exceptions in event accessors fail tests when using .Monitor()

See original GitHub issue

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!

Issue Analytics

  • State:open
  • Created a year ago
  • Comments:8 (5 by maintainers)

github_iconTop GitHub Comments

2reactions
lg2decommented, Jul 6, 2022

The method Monitor could get (optional) options to ignore specific events to be subscribed.

1reaction
apazureckcommented, Jul 10, 2022

I had this with the .ConfigureMonitoring(opt => ... ), but this is much better. I will change it this week, when I have time and throw out the configure. Thank you!

Read more comments on GitHub >

github_iconTop Results From Across the Web

CA1065: Do not raise exceptions in unexpected locations
Rule description. Methods that are not expected to throw exceptions can be categorized as follows: Property Get Methods. Event Accessor Methods.
Read more >
1211 – Catching Exceptions Originating in Property Accessors
The exception gets caught internally and converted into a binding error that you normally don't see. We can use the technique described in...
Read more >
Is it possible to monitor handled exceptions using JUnit?
Is there any way to mark test as failed if exception has occurred but was handled in catch block in the sendMessage() method?...
Read more >
How to Fix the No Such Element Exception in Java
The NoSuchElementException in Java can be thrown by various accessor methods to indicate that the element being requested does not exist.
Read more >
Exceptions should not be thrown from unexpected methods
The rule is reporting when an exception is thrown from certain methods and constructors. These methods are expected to behave in a specific...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found