cmeeren / faqt Goto Github PK

Not immediately planning this, just noting that a few assertions (like Be) might be improved by rendering some kind of diff in the assertion message.

The diff could be made via e.g. Diffract.

Drawbacks/caveats:

• Adds a dependency (if using Diffract), or significant complexity (if implementing custom differ)
• May not really be necessary
• Diffract does not diff strings, only objects?

Not immediately planning this, just noting that it could be worth investigating a compatibility checker as part of Faqt's test suite, to prevent accidental breaking changes.

Relevant links:

• PublicApiGenerator
• EraYaN/dotnet-compatibility (seemingly unofficial fork of seemingly abandoned project)
• Web search: .net prevent accidental breaking changes
• Web search: .net protect against breaking changes

Not immediately planning this, just noting that it could be worth investigating mutation testing (e.g. Stryker) to ensure good test coverage of Faqt's test suite.

Possibly relevant material: How To Test C# Unit Tests With Mutation Testing

It is possible to annotate a parameter with [<ReflectedDefinition(true)>]. The usage syntax stays the same, but it will then be of type Expr<_> and match the pattern Microsoft.FSharp.Quotations.Patterns.WithValue, where we can get the value (without having to manually evaluate the expression) as well as the expression for the parameter.

This could be used in assertions like Be(expected, isEqual) to get the name/expression of the custom comparer and include it in the assertion failure output.

Unfortunately, this has two significant drawbacks:

1. Quotations have several limitations, e.g., no calls to inner generic functions, some problems with mutable values, etc. This requires the user to adapt their code. (This is one of the reasons I no longer use Unquote.) This is made worse due to the fact that the user is seemingly not writing an expression (this fact is hidden from the user by ReflectedDefinition), likely causing confusion.

2. Sensibly printing the expression tree can be difficult. This code could be adapted, but I am unsure how complete it and what it doesn't handle, and after experimenting a bit, I find it hard to get the results I want. It seems the the expression tree does not contain enough information to render something sufficiently close to the original code, even for simple values like a curried function as the isEqual parameter.

I find that either of the points above is a sufficient reason for dropping this feature.