-
Unit testing exercises all the parts of the code. However, sometimes you want to make sure something does not compile. For example, some property can not be assigned, some constructor is not public, and so on. How can xUnit support such testing? For example, I would like to describe public properties, methods, and interfaces for classes and check that they do not suddenly have other properties, methods, and interfaces. For example, I suggest describing such a public API for classes and interfaces in the form of C# code, without implementation, and xUnit will check that the implementation corresponds to the given API. It's the same for libraries, that it doesn't have other public interfaces, classes, etc. Perhaps such a tool already exists, I just do not know about it. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
I'd say there's not much xunit specific to your request; as such, it may make sense to ask on stack overflow? I've seen people (e.g. https://github.com/Azure/azure-cosmos-dotnet-v3) do such API surface testing by having a text file in the repo with a known state, and then programmatically walk the binary and see if they are still the same. When something mismatches, the dev can then either update the expected result to reflect the new shape, or fix the problem. The name of that general technique escapes me atm (there are libs that focus on providing assertion helpers for showing diffs from object trees cleanly). (In the small, one might use the term characterization test, but that's not the term that's eluding me right now) I'd say the bottom line is that any such support is more a generic tool that could equally be triggered from other test frameworks. Given that's the case, adding stuff orthogonal stuff into xunit's core libraries is not justified. |
Beta Was this translation helpful? Give feedback.
I'd say there's not much xunit specific to your request; as such, it may make sense to ask on stack overflow?
I've seen people (e.g. https://github.com/Azure/azure-cosmos-dotnet-v3) do such API surface testing by having a text file in the repo with a known state, and then programmatically walk the binary and see if they are still the same. When something mismatches, the dev can then either update the expected result to reflect the new shape, or fix the problem.
The name of that general technique escapes me atm (there are libs that focus on providing assertion helpers for showing diffs from object trees cleanly). (In the small, one might use the term characterization test, but that's not t…