# MyTested.AspNetCore.Mvc: fluent ASP.NET Core controller testing > MyTested.AspNetCore.Mvc is a strongly typed, test-runner-independent library for ASP.NET Core MVC controller tests. It centralizes request setup, service mocking, and response assertions, but its custom licence and package version should be checked before adoption. **ivaylokenov/MyTested.AspNetCore.Mvc** — Fluent testing library for ASP.NET Core MVC. - Repository: https://github.com/ivaylokenov/MyTested.AspNetCore.Mvc - Website: https://docs.mytestedasp.net/ - Stars: 1,709 · Forks: 173 - Language: C# - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/ivaylokenov-mytested-aspnetcore-mvc ## Why MyTested.AspNetCore.Mvc targets MVC controller tests MyTested.AspNetCore.Mvc addresses the repetitive part of testing ASP.NET Core MVC controllers: constructing requests, supplying mocked dependencies, invoking controller actions, and checking the returned result. The README describes the project as a strongly typed unit testing library with a fluent interface for ASP.NET Core MVC, covering both MVC controllers and API scenarios. Its intended users are .NET developers who want controller tests that read as a sequence of test intentions rather than a collection of low-level setup and assertion calls. The library is not tied to one test runner. The README explicitly mentions xUnit and NUnit as examples, so the assertion and invocation helpers can sit inside the test structure supported by the runner already used by a project. That separation matters when an application has established conventions for fixtures, asynchronous tests, or test discovery. MyTested.AspNetCore.Mvc supplies MVC-specific testing vocabulary, while the runner remains responsible for executing and organizing tests. The README also states that the project contains more than 500 assertion methods and is covered by more than 2,500 unit tests. Those figures are project claims, not independent measurements, but they establish the intended scope: this is a broad assertion library, not a small helper for invoking one action. The repository layout includes source, test, documentation, plugins, and several sample applications, including ApplicationParts, Autofac, configuration, music-store, and startup variants. That layout suggests that integration setup and dependency-injection scenarios are part of the project’s design surface. ## Request setup, dependency resolution, and result checks The documented feature set divides the test flow into three concrete concerns. First, the built-in service mock resolver lets a test register mocks once and use them across requests. That can reduce repeated dependency substitution when several actions depend on services from the same application graph. Second, the library provides request setup for arranging fake request data before invoking an MVC action. Third, detailed response assertions validate the available result objects. The resulting workflow is intended to resemble fluent testing: arrange the request, invoke the controller, and assert on the response. The README does not expose the exact builder classes, resolver registration signature, or result hierarchy. It also does not show whether request headers, query strings, form data, route values, and body content are configured through separate APIs. Those details should be taken from the project documentation or IntelliSense rather than inferred from the feature description. The distinction between unit and integration testing is not presented as a sharp architectural boundary. The README says the library is suitable for unit or integration-style controller tests, and the repository contains samples involving `Startup`, `ApplicationParts`, Autofac, and application configuration. This means the library can fit tests that construct an MVC test host, while still providing direct assertions about controller results. It should not be confused with a browser-level test system: the documented scope is ASP.NET Core MVC request and response behavior. ## Installing MyTested.AspNetCore.Mvc and making a first test The README identifies the project as a .NET library and links to its NuGet package. It does not provide a package installation command, package version selection procedure, or a complete first-test example. Consequently, there is no verified command to reproduce here. A new user should obtain the package from the linked NuGet page and check the package target framework against the application before writing code. The repository’s `samples/README.md` and the documentation directory are project-provided places to look for sample setup. The top-level sample directories can help identify supported application shapes, including `samples/NoStartup/` and `samples/WebStartup/`. Neither the sample filenames nor the shortened README establishes which ASP.NET Core versions a particular sample targets, so version compatibility should be checked in the project files and package metadata. A first practical use should follow a narrow sequence. Install the package in the test project, select an existing controller test fixture, register the mocked application services required by that fixture, invoke one action through the library’s documented fluent API, and add the result assertion that matches the expected status, view, redirect, or other MVC output. The exact method names must come from the package’s current API documentation. Do not copy an invented namespace or fluent call based solely on the high-level feature list. ## Choosing the right test boundary in ASP.NET Core projects MyTested.AspNetCore.Mvc is a reasonable candidate when the test needs to reason about MVC controller behavior: action invocation, model or view results, redirects, validation-related responses, route context, or controller dependencies. Its built-in resolver and request helpers are most relevant when several tests share the same application setup. The library’s runner independence also makes it compatible with projects that standardize on xUnit or NUnit, provided the package and API match their supported .NET environment. It is the wrong tool when the test is primarily about browser rendering, JavaScript behavior, network calls from a browser, or end-to-end user workflows. The repository description does not claim those capabilities. It is also a poor fit for testing unrelated .NET libraries, because its assertions and setup are centered on ASP.NET Core MVC. A test that only exercises a domain service can usually remain in the project’s normal unit-test layer without introducing this dependency. There is a second boundary worth checking before adoption: whether the desired test needs a complete server pipeline or only an isolated controller. The samples include startup and configuration cases, which indicates support for richer MVC setups, but the README does not document every runtime component, middleware behavior, or hosting limitation. A library that can assert an MVC result should not be treated as proof that all ASP.NET Core infrastructure has been exercised. ## Comparison with direct xUnit or NUnit MVC testing The practical alternative is to build controller tests directly with xUnit or NUnit, ASP.NET Core’s own controller context types, and hand-written result assertions. That approach has fewer package-specific helpers and leaves the complete test mechanics visible. It can be preferable when a project needs unusual request construction, custom middleware behavior, or assertions that the library does not expose. MyTested.AspNetCore.Mvc differs by placing common MVC operations behind a fluent interface. The README identifies three concrete additions: a built-in service mock resolver, full request setup, and detailed response assertions. Direct runner tests still require the developer to arrange those elements manually, while this library attempts to standardize them. In exchange, adoption introduces a library-specific API and a dependency whose behavior must be checked when ASP.NET Core changes. Neither approach is universally simpler. Direct tests offer maximum control and fewer abstractions, but repeated controller tests can become verbose. MyTested.AspNetCore.Mvc offers a common vocabulary for those repeated operations, but the documentation does not establish that every MVC result or edge case is supported. A team should compare the required assertions in its own controllers with the documented feature list before choosing. ## Licence, upgrades, and project maintenance The repository is marked as not archived, and its last push was on 2026-10-03. Recent releases include `10.0.0` on 2026-09-29, `9.0.0` on 2025-03-03, and `8.0.0` on 2023-11-19. These dates indicate recent repository activity, but they do not guarantee compatibility with every .NET or ASP.NET Core version. The repository declares a custom licence that GitHub cannot classify. The README does not summarize its permissions or restrictions. Before using the package in a commercial application or distributing a project that depends on it, the team should read the `LICENSE` file and confirm the permitted uses, redistribution terms, attribution requirements, and warranty language. This is a repository-specific licensing check, not a conclusion based on the package’s open source label. Upgrades can require review because the package has followed major version lines, including 8, 9, and 10. The repository’s `development` branch is the default branch, while the README links version-specific documentation and examples in places. Consumers should compare the selected package version with the target framework and inspect the release-specific API before upgrading an existing test suite. ## Conclusion Adopt MyTested.AspNetCore.Mvc when an ASP.NET Core MVC test suite benefits from one fluent API for request preparation and result validation. Do not choose it for non-MVC tests or when a custom licence is unacceptable without review. Verify package compatibility with the target ASP.NET Core version, the availability of required assertions, and the terms in LICENSE before adding it to a project. ## FAQ ### What is MyTested.AspNetCore.Mvc used for? It is a strongly typed, fluent testing library for ASP.NET Core MVC controller and API scenarios. The documented focus is request setup, service mocking, and assertions over MVC result objects. ### Does MyTested.AspNetCore.Mvc work with xUnit and NUnit? Yes. The README describes the library as test-framework agnostic and gives xUnit and NUnit as examples of test runners that can be combined with it. ### What should I check before installing MyTested.AspNetCore.Mvc? Check the NuGet package metadata against the application’s ASP.NET Core and .NET target, then read the repository’s custom `LICENSE` file. The README links to the NuGet package but does not provide a complete installation command. ## Sources - [Issues](https://github.com/ivaylokenov/MyTested.AspNetCore.Mvc/issues) - [ivaylokenov/MyTested.AspNetCore.Mvc on GitHub](https://github.com/ivaylokenov/MyTested.AspNetCore.Mvc) - [Project website](https://docs.mytestedasp.net/) - [README](https://github.com/ivaylokenov/MyTested.AspNetCore.Mvc/blob/development/README.md) - [Releases](https://github.com/ivaylokenov/MyTested.AspNetCore.Mvc/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ivaylokenov-mytested-aspnetcore-mvc