nunit / nunit/nunit-console

Explore command (--explore) does not report issues while generating Test Cases

Open
#658 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Needs Discussion V4
Dominant language
C#
Stars
234
Forks
163
Avg merge
13h 32m
Merged PRs (30d)
25

Description

I found strange inconsistency in behaviour of NUnit.ConsoleRunner between explore and execute when there are "problematic" test cases - i.e. an exception thrown when resolving TestCaseSource values. Generally speaking, I would like to:

  1. Get some indicator that exploration (i.e. result of --explore) didn't went quite well, as there were issues with generating cases.
  2. See more details, when given test could not executed (by its "exact name") because cases were not generated.

If current behaviour is "by design", I would be very glad to get an explanation why there is such difference. Also, I would like to find such information in documentation, but I was unable to.

I'm also very surprised that NUnit will not complain much, when it was instructed to execute test (by "exact name"), but such test could not be found (e.g. nobody yet created one). It looks risky (at least for me), to return 0 when no test (especially requested) was executed, as it will hide issues with infrastructure which uses NUnit (e.g. incorrectly provided tests names). On the other hand, it is not my main concern here.


Nonetheless, I've prepared demo (NUnitInconsistency.zip, sources), and I believe that my explanation isn't convoluted much. All outputs are trimmed to significant ends.

It is a simple .NET (4.7.1, class-lib) project with NuGet dependencies to NUnit (3.12.0) and NUnit.ConsoleRunner (3.10.0). It is basically single C# file, which is relevant for this issue:

using System;
using NUnit.Framework;

namespace NUnitInconsistency
{
    public class ExecuteVsExploreTests
    {
        private const bool ShouldCauseProblems = false;

        public static string[] ProblematicSource()
        {
            if (ShouldCauseProblems)
                throw new Exception("Problem!");

            return new[] { "First", "Omega" };
        }

        [TestCaseSource(nameof(ProblematicSource))]
        public void InconsistencyTest(string value)
            => Assert.IsNotEmpty(value, "Just for show");
    }
}

(I) When it's compiled (after NuGet restore, then Debug build), tests could be executed and given assembly can be "tested" via console (cmd.exe):

> packages\NUnit.ConsoleRunner.3.10.0\tools\nunit3-console.exe NUnitInconsistency\bin\Debug\NUnitInconsistency.dll
Test Run Summary
  Overall result: Passed
  Test Count: 2, Passed: 2, Failed: 0, Warnings: 0, Inconclusive: 0, Skipped: 0

> echo Exit code: %errorlevel%
Exit code: 0

(II) Also tests could be "explored" to find their "exact names" in given compiled assembly:

> packages\NUnit.ConsoleRunner.3.10.0\tools\nunit3-console.exe NUnitInconsistency\bin\Debug\NUnitInconsistency.dll --explore
NUnitInconsistency.ExecuteVsExploreTests.InconsistencyTest("First")
NUnitInconsistency.ExecuteVsExploreTests.InconsistencyTest("Omega")

> echo Exit code: %errorlevel%
Exit code: 0

(III) Everything works fine and as expected. However, let's assume that we encounter some problems while generating cases (just change ShouldCauseProblems to true and rebuild). So as a result, when executing tests, we will get appropriate ExitCode, and expected Overall result: Failed with detailed exception & stack-trace (omitted here):

> packages\NUnit.ConsoleRunner.3.10.0\tools\nunit3-console.exe NUnitInconsistency\bin\Debug\NUnitInconsistency.dll
Test Run Summary
  Overall result: Failed
  Test Count: 1, Passed: 0, Failed: 1, Warnings: 0, Inconclusive: 0, Skipped: 0
    Failed Tests - Failures: 0, Errors: 0, Invalid: 1

> echo Exit code: %errorlevel%
Exit code: 1

(IV) Nonetheless, under those circumstance (problem with generating test cases), when someone would like to find what tests are available in given assembly, they will get "everything" without problems, but at the same time, tests will be generated without arguments in names (i.e. just name of test), and nobody know that there is an issue:

> packages\NUnit.ConsoleRunner.3.10.0\tools\nunit3-console.exe NUnitInconsistency\bin\Debug\NUnitInconsistency.dll --explore
NUnitInconsistency.ExecuteVsExploreTests.InconsistencyTest

> echo Exit code: %errorlevel%
Exit code: 0

(V) I guess, it is not a big deal, as one can always execute all test under its common name (i.e. without any arguments), and when there is a problem with generating cases, you will find expected behaviour - very similar to (III):

> packages\NUnit.ConsoleRunner.3.10.0\tools\nunit3-console.exe NUnitInconsistency\bin\Debug\NUnitInconsistency.dll --test NUnitInconsistency.ExecuteVsExploreTests.InconsistencyTest
Test Run Summary
  Overall result: Failed
  Test Count: 1, Passed: 0, Failed: 1, Warnings: 0, Inconclusive: 0, Skipped: 0
    Failed Tests - Failures: 0, Errors: 0, Invalid: 1

> echo Exit code: %errorlevel%
Exit code: 1

(VI) In like manner, let's assume that one has got full names of tests with arguments, and only later, the issue with generating test cases come up, but nobody knows that yet. Then, one tries to execute single test by its "exact name":

> packages\NUnit.ConsoleRunner.3.10.0\tools\nunit3-console.exe NUnitInconsistency\bin\Debug\NUnitInconsistency.dll --test "NUnitInconsistency.ExecuteVsExploreTests.InconsistencyTest(\"Omega\")"
Test Run Summary
  Overall result: Passed
  Test Count: 0, Passed: 0, Failed: 0, Warnings: 0, Inconclusive: 0, Skipped: 0

> echo Exit code: %errorlevel%
Exit code: 0

Clearly "no tests executed", but also no errors printed - with information that such test case could not be found, as no cases could be generated. Moreover, let's assume that the one is a script (CI/CD agent) and doesn't care about output, it only care about exit code, but in such case, everything went OK, as %errorleverl% is 0.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the NUnit.ConsoleRunner --explore and --test behavior described in the issue, using the linked NUnitInconsistency example and its ExecuteVsExploreTests class to reproduce both cases. Compare exploration and execution results when TestCaseSource throws, then verify that errors are reported and the exit code reflects the failure or missing requested test.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
cli, testing-qa
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.