fluentassertions / fluentassertions/fluentassertions.analyzers
No FAA0001 when `?.` is followed by `Should().BeApproximately`
- Dominant language
- C#
- Stars
- 131
- Forks
- 25
- PR merge metrics
- No merged PRs in 30d
Description
Suppose for the sake of this bug report that we have the following type:
```csharp
public interface IExample {
double Amount { get; }
}
```
Then if we write the following **incorrect** test:
```csharp
public void TestMethod() {
IExample? actual = null;
actual?.Amount.Should().BeApproximately(3.14, 0.01); // no FAA0001 here?!
}
```
then we get no message from `FluentAssertions.Analyzers` about the wrong code.
For other assertions, this works fine. For example:
```csharp
actual?.Amount.Should().BeGreaterThan(3.1); // good, we get 'FAA0001: Use .Should() instead of ?.Should()'
```
or:
```csharp
actual?.Amount.Should().BePositive(); // good, we get 'FAA0001: Use .Should() instead of ?.Should()'
```
or:
```csharp
actual?.Amount.Should().BeInRange(3.1, 3.2); // good, we get 'FAA0001: Use .Should() instead of ?.Should()'
```
We need the FAA0001 with `.BeApproximately(3.14, 0.01)` as well. Without it, the author may think his tests proves `actual` is an instance where `Amount` equals `3.14` within a tolerance of `0.01` when in fact `actual` is a null reference (and no `Amount` exists).
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reproducing the issue with the C# example using `actual?.Amount.Should().BeApproximately(3.14, 0.01)`, then compare FAA0001 handling for BeApproximately with BeGreaterThan, BePositive, and BeInRange. Done means the analyzer reports FAA0001 for the BeApproximately case while preserving the existing behavior for the other assertions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- testing-qa
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 68/100