Integration Tests for ASP.NET Core

[JeremyCaney]

ASP.NET Core relies on a number of framework conventions that make it cumbersome to unit test—and which, in some cases, might even limit the benefits of unit testing. This makes them well-suited for integration tests.

Scope

In particular, the following are areas that are difficult to meaningfully unit test but trivial to setup integration tests for:

• Routing and associated extension methods
• Dynamic selection of views based on contextual data
• Searching for views on the file system

Performance

The most expensive part of this process is loading a comprehensive database. Given that, the optimal solution will be to establish a stub ITopicRepository with hard-coded data which can be loaded into memory.

Host

Integration testing works hand in-hand with a host project. We already have a host project. But it typically operates off of a live SqlTopicRepository in order to evaluate against real-world conditions. Can this be modified to conditionally use a stub repository, possibly by selecting an alternateStartup? Or should it be a separate, lighter weight project intended exclusively as a test harness? Likely the latter.

Tests

• Define view by:
  • Query String
  • Header
  • Topic
• Find views in:
  • /Views/ContentTypes/{ContentType}[.{View}].cshtml
  • /Views/{ContentType}/{ContentType|View}.cshtml
  • /Views/{Controller}/{Action}.cshtml
  • /Views/Shared/{View}.cshtml
• Route by:
  • /{rootTopic}/{path}
  • /{area}/{path}
  • /{area?}/{controller}/{action?}/{id?}
  • /{area}/{action?}/{id?}

Git Repository

If we combine the core library, the hosts, the unit tests, and the integration tests, we’re looking at 3-5 projects which are closely related, but only loosely dependent on the other core projects. Does it make sense to move these to a new git repository? That makes good organizational sense, but makes it harder to coordinate versioning, metapackage inclusion, deeply integrated features, and testing. The latter might be solvable with conditional local project dependencies, possibly via a separate reference host repository.

[JeremyCaney]

Established a special host and StubTopicRepository exclusively for the integration tests so that they can operate against light-weight, in-memory data instead of a SQL database, thus allowing them to run in the Azure DevOps CI/CD pipeline. The integration tests themselves covers the ServiceCollectionExtensions, TopicViewLocationExpander, and TopicViewResultExecutor. Other elements of the ASP.NET Core adapter, such as the controllers and view components, may be indirectly covered by these tests, but are also covered by the existing unit tests, and thus weren't a coverage priority; the integration tests, instead, focus on the components that are difficult or impractical to unit test (e315506).