The unit tests need to be rearchitected

Assemblies Affected

ASP.NET Core OData 7.x and later

Describe the Problem

Over the past several months, I have been experiencing a level of instability with this project that makes it difficult to rely on from build to build. As an example, there have been several documented instances in the last few months of package reference failures spanning multiple releases, and now I'm tracking down issues with Batching and a NullReferenceException inside Microsoft.AspNetCore.OData 7.6.1's ODataResourceDeserializationHelpers in were not in previous builds.

I believe the problem stems from the fact that the unit tests are entirely too complicated to maintain. I don't know if it's still this way now, but when I rearchitected the OData 8.x branch before its release, I noticed the following issues:

• No fewer than 3 different ways to spin up unit tests
• Each individual unit test has a ton of setup and boilerplate work before it can actually get to the things it's testing
• There are not really clear distinctions between true unit tests and integration tests
• There are not enough tests for unhappy paths

That cognitive load has a massive impact on maintainability and gives a false sense of security on code coverage.

We experienced the same thing on the Restier project several years ago and as a result I developed the Breakdance platform to make WebApi and OData testing easier.

Suggested Remediation

Now that Restier has gone GA and it comes with a built-in testing framework (Microsoft.Restier.Breakdance), I believe it is time to look at implementing Breakdance in the entire OData stack moving forward. It would eliminate thousands of lines of unnecessary code, give the team an opportunity to build true unit tests that cover more edge-cases per method, and let the team spend more time developing tests that can provide better stability guarantees.

Additional Context

Here's an example of how easy an integration test can be with Breakdance:
https://github.com/OData/RESTier/blob/main/src/Microsoft.Restier.Tests.AspNet/FeatureTests/ActionTests.cs

Here's an example of leveraging DI container outputs between releases to maintain compatibility:
https://github.com/OData/RESTier/blob/main/src/Microsoft.Restier.Tests.Legacy/LegacyDependencyInjectionTests.cs

Here's an example of how we use Breakdance to test Breakdance:
https://github.com/OData/RESTier/blob/main/src/Microsoft.Restier.Tests.Breakdance/RestierBreakdanceTestBase_CoreTests.cs

Start by reviewing the existing test setup in the ASP.NET Core OData repository and compare it with the referenced RESTier Breakdance examples: ActionTests.cs, LegacyDependencyInjectionTests.cs, and RestierBreakdanceTestBase_CoreTests.cs. Define the test categories and migration scope before changing code; done means a maintainable test architecture with clearer unit/integration boundaries and broader unhappy-path coverage.