0
votes

I have a OneTimeSetup where I want to verify integration connections prior to running tests (databases, REST endpoints, etc.), short-circuiting the suite if there is an issue. Consider something like

Try
    Dim testContext As DBContext = New DBContext(_configuredConnectionString)

    VerifySQLConnection(testContext)
Catch ex As Exception
    Dim actionableError As String = String.Format(_VERIFY_SQL_CONNECTION_TEMPLATE, _configuredConnectionString)
    Dim actionableException As New ConfigurationException(actionableError, ex)
    'Throw actionableException

    Assert.Inconclusive(actionableError)
End Try

If a connection fails, I don't want to fail the test, I want to assert that the entire suite is inconclusive, because the actual test never ran.

I'm noticing that Assert.Inconclusive lacks an overload taking in an inner exception. This forces me to either fail all tests, with a full inner exception to inspect, or mark tests as inconclusive, but lose actionable information from an NUnit test runner window.

  • Is there a reason for this or is this overload missing an oversight?
  • Is there an alternative I could use to get both Inconclusive and the full inner exception (not just the message, but stack, etc.)?
1

1 Answers

2
votes

NUnit's Inconclusive result is intended to mean that the test simply cannot be run because some pre-condition has not been met. The fact that an exception happens to be thrown is part of the internal implementation - it's how we force the test to stop running at that point - but nothing about the nature of the exception is exposed to the user.

Assert.Inconclusive is a manual way to provide such an Inconclusive result. It does so absolutely, without making any particular test, in a similar way to how Assert.Fail works. If you want to make a test of some kind, it is "assumed" that you will use the Assume.That method to produce the result.

In your case, the VerifySqlConnection method sounds like something you should be testing in at least one test method, failing if you can't make it. For other tests that depend on a connection having been made, you could use code similar to...

Assume.That(() => VerifySqlConnection(testContext), Throws.Nothing);

The above is the C# syntax... I leave VB translation to you. :-)