Can I logging assertions(success and fails) or add assertions to steps?

[VictorYakushenko]

Description

I would like to log assertions into steps (Allure for example) and other logs. Can I just add a logger or another handler so I don't have to do it for every assertion? Like HttpMessageHandler in HttpClient

[dennisdoomen]

No, FA doesn't have any built-in logging, with the exception of the Should().BeEquivalentTo() API. That one supports a ITraceWriter.

[VictorYakushenko]

Are you planning to add a handler for adding some decorators in the future?

[dennisdoomen]

I'm not sure what you mean. What kind of logging are you trying to collect?

[VictorYakushenko]

For example, wrap assertion in the step of the report (for example Allure) and add assertion description as step description. Of course, I can do this separately for each assert, but I would like to have one Handler, especially since the Fluent assertion framework already builds good descriptions

[dennisdoomen]

Ah, maybe you can use the ThrowException delegate on the Services class. See

fluentassertions/Src/FluentAssertions/Common/Services.cs

Line 37 in 344784d

public static Action<string> ThrowException { get; set; }

[VictorYakushenko]

Can I use it when success assertion? DelegatingHandler in HttpClient is the example that most fits. Or like ThrowException but for the entire assertion:
This is the dummy code below just for the example

public static Action<AssertionScope, string> AssertionHandler { get; set; }

public void SomeHandler(AssertionScope scope, string description)
{
    Console.WriteLine($"Before Assertion: {description}");
    scope.ExecuteAssertion();
    Console.WriteLine($"After Assertion: {description}");
}

[dennisdoomen]

Can I use it when success assertion? DelegatingHandler in HttpClient is the example that most fits. Or like ThrowException but for the entire assertion:

No, I can't think of a way to do that. It wasn't designed for that purpose.

[VictorYakushenko]

Ok, Thanks

[xadvfh]

This would really be a great thing to have. Lots of companies are requiring logs/reports for audit purpose and it would be nice to have a way to record pass and failures

[WolfBublitz]

Are there any new plans to introduce such a feature?

[VictorYakushenko]

Many people need this functionality, are there any options to implement it?

[jnyrup]

There no new plans, the design hasn't changed since:

It wasn't designed for that purpose.

I'm still not sure what it is that you want to log and where you want to invoke/control this.
Please provide a complete code example of what you imagine.

[VictorYakushenko]

Need an opportunity to add global function or handler like in Http Client which give access to assertion description and expected result which created while assert fail but for all assertions.
A striking example: https://stackoverflow.com/questions/18924996/logging-request-response-messages-when-using-httpclient
If the handler does not fit, just add a function that will wrap all assertions like in example abow

In general, this is just a wrapper with the ability to process and log asserts for test reporters

[jnyrup]

Nothing is "just" when designing a library used by thousands and thousands.

This sounds more like a job for the test runner.

[TestClass]
public class UnitTest2
{
    public TestContext TestContext { get; set; }

    [TestInitialize]
    public void Before()
    {
        TestContext.WriteLine("About to run {0}", TestContext.TestName);
    }

    [TestMethod]
    public void MyTest()
    {
        TestContext.Properties.Add("description", "my description");
    }

    [TestCleanup]
    public void After()
    {
        TestContext.WriteLine("description:{0}", TestContext.Properties["description"]);

        if (TestContext.CurrentTestOutcome == UnitTestOutcome.Passed)
        {
            TestContext.WriteLine("{0} passed!", TestContext.TestName);
        }
    }
}

If I'm misinterpreting you, please provide a complete code example of how you imagine such a the test to look like.

[VictorYakushenko]

It is my simple example for NUnit. Execute is method which wrap assertion, It should be executed iside fluent assertion framework
AssertHandler.Execute(description, () => Assert.That(() => func(), constrain, $"Verify Result: {description}"));

[WolfBublitz]

Hi, let me explain my point of view:

At the moment I have used FluentAssertions (FA) for writing CI tests unit tests, integration tests, etc executed with MSTest. For this purpose FA is really great and makes writing assertions a lot more convenient.

[TestMethod]
public void MyTest()
{
    Assert.AreEqual(1, 2);
    // vs.
    1.Should.Be(2);
}

I think it is out of question that FA makes it far more easier to read.

At work I am currently maintaining a test framework for testing hard- and software developed by my company. I cannot go into details since the whole system is proprietary but at the end writing test with this system is similar to writing tests with MSTest. There are values (gathered some home how, e.g. from a measurement device) that are checked against expected values. This is done by writing assertions and at the moment they look similar to the methods provided by MSTest.

My idea is now to use FA for writing assertions because FA is much more expressive and has far more features (like object comparison, exception checking, etc. and of course very nice default messages). I have already tried to integrate FA into our systems which was not such a big deal but there is one point that is a blocking issue for me:

While FA provides very nice failure messages there are no messages in case of success and as far as I see it there is currently no possibility for me to enable them (without forking FA and modifying it the way I need (which is not really an option)).

Why is this so important for me?

1. I want to provide the excellent API of FA to our users.
2. In our test environment it is very important to provide test reports and this reports typically list all tests (meaning all assertions) that were executed. In general the reader does not inspect the source code of the test and this way he can easily check what kind of checks were done. He wants to see the successful and the failed ones. This is even more important in case the report is forwarded to another authority. It must easily understandable.

Proposal

Provide an API in FA to enable custom logging of assertion messages. There could be two delegates on for success and one for failure. They should provide the following parameters:

• subject
• expected value
• type of assertion (e.g. equality, less than, etc ..)
• location (file and line) <- optional but would be nice

Default behaviour: The current behaviour.

[VictorYakushenko]

Why is it problem to wrap with handles places where assertion happens? What design specific things block it?

[VictorYakushenko]

As I understand FA has several assertion types, so to each of them should be added handler. I did similar with NUnit, it is need to build constraints and description then execute Assert That in one place with empty or inner decorator. But it is bad because I have to build description for a lots of cases which FA already has

[dennisdoomen]

Why is it problem to wrap with handles places where assertion happens? What design specific things block it?

Because the implementation of how the various assertion methods work is not entirely consistent. If I understand you correctly, you would care about the assertion operation, the subject and expectation and the outcome. And this becomes increasingly complicated with BeEquivalentTo, which executes a deep comparison of the selected members.

I don't see value in this kind of investment, but if somebody could come up with a pattern how to implement that and offer a PR (after approval), it's not going to happen.

[VictorYakushenko]

Ok, I will watch solutions. But I think it should not depends on assertion complexity

[SeMuell]

@dennisdoomen and @jnyrup
Since we are also needing this feature due to requirements from regulatory for our formal tests I looked into some ways dealing with this.

One way I thought could work as a workaround would be using the AssertionScope class and the FailWith method. Unfortunately, the class itself is sealed (plus the AssertionScope.Current is also not referring to IAssertionScope) and I didn't had time to try it in the source yet.

private Continuation FailWith(Func<string> failReasonFunc)
{
    try
    {
        bool failed = succeeded != true;

        string result = failReasonFunc();

        if (expectation is not null)
        {
            result = expectation() + result;
        }

        if (failed)
        {
            assertionStrategy.HandleFailure(result.Capitalize());

            succeeded = false;
        }
        else
        {
            assertionStrategy.HandleSuccess(result.Capitalize());
        }

        return new Continuation(this, continueAsserting: !failed);
    }
    finally
    {
        succeeded = null;
    }
}

The drawback on this workaround is the message of course, since it is still something like Expected plan to be <null>, but found <null>,