Pull Request Test Coverage Report for Build 2100620689

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 22 of 22 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+1.2%) to 96.125%

Totals
Change from base Build 2095605309:	1.2%
Covered Lines:	11904
Relevant Lines:	12217

💛 - Coveralls

Maybe using the OccurrenceConstaints for asserting on the expected count?

It's a bit difficult to review, when the APIs keep changing 😉
You can always mark a PR as draft.

We are trying to formalize the process of changes a bit, such that larger changes are first discussed in an issue before opening a PR.
Typos and alike are always welcome and don't need to go through an issue.

We haven't fully set on the process, but these links should provide a feeling of it, notably excluding the amount of manpower we can allocate.
https://devblogs.microsoft.com/dotnet/api-review-process-for-net-core/
https://github.com/dotnet/runtime/blob/main/docs/project/api-review-process.md

This PR just finishes an already discussed feature.
The only difference by now is to use the OccurrenceConstraint, which makes more sense IMO

ahh.. and btw. This state is my „final“ change 🙃

@dennisdoomen What do you think: Should I remove the HaveSingleElement() method?

HaveSingleElement() reads less "fluent" than HaveElement("x", Exactly.Once());

I have to admit I agree. The only case where it would read fluent if there was a parameterless HaveSingleElement.

Is the the API change we can agree on?

class XDocumentAssertions
{
+    AndWhichConstraint<XDocumentAssertions, IEnumerable<XElement>> HaveElement(string expected, OccurrenceConstraint occurrenceConstraint, string because = "", params object[] becauseArgs)
+    AndWhichConstraint<XDocumentAssertions, IEnumerable<XElement>> HaveElement(XName expected, OccurrenceConstraint occurrenceConstraint, string because = "", params object[] becauseArgs)
}

class XElementAssertions
{
+    AndWhichConstraint<XElementAssertions, IEnumerable<XElement>> HaveElement(string expected, OccurrenceConstraint occurrenceConstraint, string because = "", params object[] becauseArgs)
+    AndWhichConstraint<XElementAssertions, IEnumerable<XElement>> HaveElement(XName expected, OccurrenceConstraint occurrenceConstraint, string because = "", params object[] becauseArgs)
}

Is the the API change we can agree on?

Yep