Skip to main content
Added an appendix
Source Link
Paul Kertscher
  • 2.4k
  • 1
  • 16
  • 21

This strongly depends on the language and framework used. Speaking in terms of NUnit, there are Assert.Throws(...) methods. You can pass them a lambda method:

Assert.Throws(() => rangeValidator.EnsureValid(-5))

which is executed within the Assert.Throws. The call to the lambda will most likely be wrapped by a try { } catch { } block and the assertion fails, if an exception is caught.

If your framework does not provide these means, you could work it around, by wrapping the call by yourself (I'm writing in C#):

// assert that the method does not fail
try
{
    rangeValidator.EnsureValid(50);
}
catch(Exception e)
{
    Assert.IsTrue(false, $"Exception: {e.Message}");
}

// assert that the method does fail
try
{
    rangeValidator.EnsureValid(50);
    Assert.IsTrue(false, $"Method is expected to throw an exception");
}
catch(Exception e)
{
}

This makes the intention more clear, but clutters the code to a certain extent. (Of course you can wrap all this stuff in a method.) At the end it will be up to you.

Edit

As Doc Brown pointed out in the comments, the issue has not been to indicate that the method throws, but that it does not throw. In NUnit there is also an assertion for that

Assert.DoesNotThrow(() => rangeValidator.EnsureValid(-5))

This strongly depends on the language and framework used. Speaking in terms of NUnit, there are Assert.Throws(...) methods. You can pass them a lambda method:

Assert.Throws(() => rangeValidator.EnsureValid(-5))

which is executed within the Assert.Throws. The call to the lambda will most likely be wrapped by a try { } catch { } block and the assertion fails, if an exception is caught.

If your framework does not provide these means, you could work it around, by wrapping the call by yourself (I'm writing in C#):

// assert that the method does not fail
try
{
    rangeValidator.EnsureValid(50);
}
catch(Exception e)
{
    Assert.IsTrue(false, $"Exception: {e.Message}");
}

// assert that the method does fail
try
{
    rangeValidator.EnsureValid(50);
    Assert.IsTrue(false, $"Method is expected to throw an exception");
}
catch(Exception e)
{
}

This makes the intention more clear, but clutters the code to a certain extent. (Of course you can wrap all this stuff in a method.) At the end it will be up to you.

This strongly depends on the language and framework used. Speaking in terms of NUnit, there are Assert.Throws(...) methods. You can pass them a lambda method:

Assert.Throws(() => rangeValidator.EnsureValid(-5))

which is executed within the Assert.Throws. The call to the lambda will most likely be wrapped by a try { } catch { } block and the assertion fails, if an exception is caught.

If your framework does not provide these means, you could work it around, by wrapping the call by yourself (I'm writing in C#):

// assert that the method does not fail
try
{
    rangeValidator.EnsureValid(50);
}
catch(Exception e)
{
    Assert.IsTrue(false, $"Exception: {e.Message}");
}

// assert that the method does fail
try
{
    rangeValidator.EnsureValid(50);
    Assert.IsTrue(false, $"Method is expected to throw an exception");
}
catch(Exception e)
{
}

This makes the intention more clear, but clutters the code to a certain extent. (Of course you can wrap all this stuff in a method.) At the end it will be up to you.

Edit

As Doc Brown pointed out in the comments, the issue has not been to indicate that the method throws, but that it does not throw. In NUnit there is also an assertion for that

Assert.DoesNotThrow(() => rangeValidator.EnsureValid(-5))

This strongly depends on the language and framework used. Speaking in terms of NUnit, there are Assert.Throws(...) methods. You can pass them a lambda method:

Assert.Throws(() => rangeValidator.EnsureValid(-5))

which is executed within the Assert.Throws. The call to the lambda will most likely be wrapped by a try { } catch { } block and the assertion fails, if an exception is caught.

If your framework does not provide these means, you could work it around, by wrapping the call by yourself (I'm writing in C#):

// assert that the method does not fail
try
{
    rangeValidator.EnsureValid(50);
}
catch(Exception e)
{
    Assert.IsTrue(false, $"Exception: {e.Message}");
}

// assert that the method does not fail
try
{
    rangeValidator.EnsureValid(50);
    Assert.IsTrue(false, $"Method is expected to throw an exception");
}
catch(Exception e)
{
}

This makes the intention more clear, but clutters the code to a certain extent. (Of course you can wrap all this stuff in a method.) At the end it will be up to you.

This strongly depends on the language and framework used. Speaking in terms of NUnit, there are Assert.Throws(...) methods. You can pass them a lambda method

Assert.Throws(() => rangeValidator.EnsureValid(-5))

which is executed within the Assert.Throws. The call to the lambda will most likely be wrapped by a try { } catch { } block and the assertion fails, if an exception is caught.

If your framework does not provide these means, you could work it around, by wrapping the call by yourself (I'm writing in C#)

// assert that the method does not fail
try
{
    rangeValidator.EnsureValid(50);
}
catch(Exception e)
{
    Assert.IsTrue(false, $"Exception: {e.Message}");
}

// assert that the method does not fail
try
{
    rangeValidator.EnsureValid(50);
    Assert.IsTrue(false, $"Method is expected to throw an exception");
}
catch(Exception e)
{
}

This makes the intention more clear, but clutters the code to a certain extent. (Of course you can wrap all this stuff in a method.) At the end it will be up to you.

This strongly depends on the language and framework used. Speaking in terms of NUnit, there are Assert.Throws(...) methods. You can pass them a lambda method:

Assert.Throws(() => rangeValidator.EnsureValid(-5))

which is executed within the Assert.Throws. The call to the lambda will most likely be wrapped by a try { } catch { } block and the assertion fails, if an exception is caught.

If your framework does not provide these means, you could work it around, by wrapping the call by yourself (I'm writing in C#):

// assert that the method does not fail
try
{
    rangeValidator.EnsureValid(50);
}
catch(Exception e)
{
    Assert.IsTrue(false, $"Exception: {e.Message}");
}

// assert that the method does fail
try
{
    rangeValidator.EnsureValid(50);
    Assert.IsTrue(false, $"Method is expected to throw an exception");
}
catch(Exception e)
{
}

This makes the intention more clear, but clutters the code to a certain extent. (Of course you can wrap all this stuff in a method.) At the end it will be up to you.

Source Link
Paul Kertscher
  • 2.4k
  • 1
  • 16
  • 21

This strongly depends on the language and framework used. Speaking in terms of NUnit, there are Assert.Throws(...) methods. You can pass them a lambda method

Assert.Throws(() => rangeValidator.EnsureValid(-5))

which is executed within the Assert.Throws. The call to the lambda will most likely be wrapped by a try { } catch { } block and the assertion fails, if an exception is caught.

If your framework does not provide these means, you could work it around, by wrapping the call by yourself (I'm writing in C#)

// assert that the method does not fail
try
{
    rangeValidator.EnsureValid(50);
}
catch(Exception e)
{
    Assert.IsTrue(false, $"Exception: {e.Message}");
}

// assert that the method does not fail
try
{
    rangeValidator.EnsureValid(50);
    Assert.IsTrue(false, $"Method is expected to throw an exception");
}
catch(Exception e)
{
}

This makes the intention more clear, but clutters the code to a certain extent. (Of course you can wrap all this stuff in a method.) At the end it will be up to you.