How to Run Multiple NUnit Test Cases
Define multiple NUnit inputs with TestCase or TestCaseSource, then run all cases or select them by category from the CLI or Visual Studio.
To define several inputs for one NUnit test, add a [TestCase(...)] attribute for each input set. NUnit discovers each set as a separate test case. For larger or reusable data sets, use [TestCaseSource]. Run the project with dotnet test, or select individual discovered cases in Visual Studio Test Explorer.
1. Define a few cases with TestCase
Repeated [TestCase] attributes are the clearest option for a small set of stable examples. Each attribute supplies arguments to the same test method.
using NUnit.Framework;
public class DivisionTests
{
[TestCase(12, 3, 4)]
[TestCase(12, 2, 6)]
[TestCase(12, 4, 3)]
public void Divide_ReturnsExpectedQuotient(
int numerator,
int denominator,
int expected)
{
Assert.That(numerator / denominator, Is.EqualTo(expected));
}
}For each row, the first two values are passed to the method as inputs and the third is the expected result. NUnit creates a distinct test for each row, so a failure identifies the specific case. See the NUnit documentation for TestCase and parameterized tests.
Include edge cases as separate rows
Keep each case independent and give it a meaningful expected result. For a method that can receive invalid input, include that behavior explicitly—for example, a separate test that asserts division by zero throws. Do not put a throwing input into the successful division test above unless the method is designed to handle it as an expected result.
2. Use TestCaseSource for larger or reusable data
Move the rows into a source when they are lengthy, generated, or shared. A source member can be a field, property, or method that returns test data. Current NUnit documentation requires the source member to be static; each yielded argument set must be compatible with the test method’s parameters.
using System.Collections.Generic;
using NUnit.Framework;
public class DivisionSourceTests
{
private static IEnumerable<TestCaseData> DivisionCases()
{
yield return new TestCaseData(12, 3, 4);
yield return new TestCaseData(12, 2, 6);
yield return new TestCaseData(12, 4, 3);
}
[TestCaseSource(nameof(DivisionCases))]
public void Divide_ReturnsExpectedQuotient(
int numerator,
int denominator,
int expected)
{
Assert.That(numerator / denominator, Is.EqualTo(expected));
}
}nameof keeps the source reference tied to the member name during refactoring. The source can also yield TestCaseData with metadata such as a readable case name when that helps identify results. Consult the NUnit TestCaseSource reference for supported source forms and details.
| Choose | When it fits | Trade-off |
|---|---|---|
[TestCase] |
A handful of short, fixed argument sets | Very readable beside the test, but large lists clutter the method declaration. |
[TestCaseSource] |
Long, generated, or shared data | Keeps the method declaration compact, but source and method signatures must stay aligned. |
3. Run all cases from the command line
From the directory containing the test project, run:
dotnet testThis builds and runs the tests in the project. To run tests across a solution, pass the solution file, for example dotnet test MySolution.sln. Parameterized cases are discovered individually by the NUnit adapter, so the test results report can show each case separately.
Select categories with NUnit’s selection language
Assign categories to tests or fixtures to create meaningful groups such as Unit, Integration, or Slow. Then pass a filter to the test host with NUnit’s selection language:
dotnet test -- NUnit.Where="cat == Unit || cat == Integration"The -- separates dotnet test options from arguments passed to the test host; NUnit.Where carries the NUnit expression. Category names are case-sensitive. For example, a test marked [Category("Unit")] matches cat == Unit, but not a differently cased category. Use the category attribute and filter syntax supported by your installed NUnit framework and adapter. See NUnit’s Test Selection Language and Category documentation.
With NUnit’s console runner, the equivalent selection expression is:
nunit3-console MyTests.dll --where "cat == Unit || cat == Integration"Use the runner and filter form that match your environment. NUnit selection expressions, IDE search boxes, and other test platform filters are not interchangeable in every setup.
4. Run selected cases in Visual Studio
- Install the NUnit framework and a compatible NUnit test adapter in the test project.
- Build the solution so the adapter can discover the tests.
- Open Test Explorer and wait for discovery to finish.
- Use Run All to execute the discovered tests, or select multiple entries and choose Run Selected Tests.
Parameterized cases appear as individual entries when discovery succeeds. The adapter’s Usage documentation describes its Visual Studio behavior and options.
5. Keep cases independent and order-safe
Do not make one case depend on another case having run first. NUnit discovers parameterized cases separately, but execution order should not be inferred from the visual order of repeated attributes. A single TestCaseSource preserves the order returned by that source; when multiple data-providing attributes are combined, ordering can be undefined. Avoid using order as a dependency: make tests self-contained or express required setup explicitly.
When cases need shared setup, use NUnit setup fixtures or construct the needed state inside each case. This also makes an individual case easier to rerun after a failure.
6. Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| No parameterized cases appear in Test Explorer | The project has not built, the adapter is missing or incompatible, or discovery failed. | Build the test project, check the NUnit framework and adapter references, then refresh discovery. Review adapter output for discovery errors. |
| TestCaseSource reports that the source cannot be found | The source name is misspelled, inaccessible, or the member does not meet the required static/source shape. | Use nameof, make the source member static as required by current NUnit, and confirm it returns an enumerable of test arguments. |
| Argument conversion or parameter-count error | A source row does not match the test method’s parameter count or compatible types. | Compare every yielded argument set with the method signature. Keep expected values in the same order as the parameters. |
| The category filter selects nothing | Category spelling/case differs, the tests were not discovered, or the filter was passed to the wrong runner layer. | Confirm discovery and exact category names. With dotnet test, put NUnit’s expression after -- as NUnit.Where=.... |
| Cases run in an unexpected order | Discovery and execution order are not guaranteed by attribute display order. | Remove order dependencies; make each case independent or arrange explicit setup. |
| Only some tests run from the IDE | A Test Explorer selection or search filter may be active. | Clear the search/filter and use Run All, or inspect the selected test list before running. |
7. Performance, reliability, and cost
Parameterized cases keep related input/output checks concise, but every case still has discovery and execution work. Keep the data set focused: a very large generated matrix can slow test discovery and make failures harder to diagnose. Prefer boundary and representative cases over an accidental Cartesian product of every possible value.
For reliability, ensure each case can run in isolation and does not rely on shared mutable state. For integration cases that use external services, categorize them so a developer can choose a suitable subset locally or in a build pipeline. Running tests with dotnet test has no NUnit license fee; infrastructure cost depends on the machines and external services used by the project.
Or skip the browser setup
This guide is about NUnit rather than website screenshots, so ScreenshotNeo is not needed to define or run these tests. For a separate web-page capture task, ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. One GET request returns a PNG, JPEG, WebP, or PDF. Its clean-capture flow accepts cookie/consent banners like a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets before the shot; each step can be turned off. Bot checks/CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for AI agents.
For example, this cURL request saves a WebP capture:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpThere is also a ScreenshotNeo API guide with the request options. The same API supports full-page and element capture, viewport/device presets, PDF settings, custom CSS and JavaScript, wait conditions, request blocking, cookies and headers, caching, signed links, async jobs, bulk capture, and more. One thousand screenshots a month are free with no card; paid plans start at $5 for 3,000 screenshots. Every feature is on every plan.
Create a free ScreenshotNeo account for 1,000 screenshots a month, with no card.
FAQ
Does each TestCase attribute create a separate test?
Yes. Each argument set is discovered and reported as its own test case.
Can I reuse a TestCaseSource across tests?
Yes. A shared source is useful when multiple tests need the same data. Keep its argument shape compatible with each consuming method.
Can I run only one parameterized input?
Yes. Select that case in Test Explorer, or use the test selection support available in your installed runner and adapter.
Which NUnit versions do these docs cover?
The NUnit documentation introduction says its documentation covers NUnit 3.0 and higher. Check the documentation for your installed framework and adapter when using older versions or version-specific behavior: NUnit Documentation.
