EDIT: There is a similar question here, but the solutions only suggest workarounds and provide no insights into the cause of the issue or how to fix it. This question may still be a duplicate.
EDIT 2: It turns out this issue is only happening during debug, although it was not happening earlier. After replacing (TCheck)null with null as TCheck the tests pass when ran but throw an exception when debugged.
ORIGINAL POST:
I have a method in a unit test that looks like this
internal void EqualityAssert<TCheck, TEquatable>(TEquatable item, ... )
where TCheck : class, IEquatable<TEquatable>, TEquatable
{
// Various equality assertions that are passing
// ...
// A == null
Assert.Throws<NullReferenceException>(
() => ((IEquatable<TEquatable>)item).Equals((TCheck)null));
}
This method is called by various unit tests, and each of those tests are failing because an "Unhandled NullReferenceException was encountered" exactly where it is expected.
Assert.Throws was working properly for me earlier but I haven't been able to figure out what changed to break it.
Better to use this pattern:
[Fact]
public void Divide_TwoNumbers_ExpectException()
{
var sut = new Calculator();
var exception = Record.Exception(() => sut.Divide(10, 0));
Assert.IsType(typeof(DivideByZeroException), exception);
}
You throw exception but you should handle it.Check below code. You can modify your code according to my example.
var message = FakeRequestBuilder.CreateSettlementFileMessage();
var warning = Assert.Throws<ExF.Core.Exception.IntegrationValidationException>(
() => createSettlementFileHandler.Handle(message));
Assert.Equal(warning.ErrorCode, -1);
Related
I've got a set of test cases, some of which are expected to throw exceptions. Because of this, I have have set the attributes for these tests to expect exceptions like so:
[ExpectedException("System.NullReferenceException")]
When I run my tests locally all is good. However when I move my tests over to the CI server running TeamCity, all my tests that have expected exceptions fail. This is a known bug.
I am aware that there is also the Assert.Throws<> and Assert.Throws methods that NUnit offers.
My question is how can I make use of these instead of the attribute I'm currently using?
I've had a look around StackOverflow and tried a few things none of which seem to work for me.
Is there a simple 1 line solution to using this?
I'm not sure what you've tried that is giving you trouble, but you can simply pass in a lambda as the first argument to Assert.Throws. Here's one from one of my tests that passes:
Assert.Throws<ArgumentException>(() => pointStore.Store(new[] { firstPoint }));
Okay, that example may have been a little verbose. Suppose I had a test
[Test]
[ExpectedException("System.NullReferenceException")]
public void TestFoo()
{
MyObject o = null;
o.Foo();
}
which would pass normally because o.Foo() would raise a null reference exception.
You then would drop the ExpectedException attribute and wrap your call to o.Foo() in an Assert.Throws.
[Test]
public void TestFoo()
{
MyObject o = null;
Assert.Throws<NullReferenceException>(() => o.Foo());
}
Assert.Throws "attempts to invoke a code snippet, represented as a delegate, in order to verify that it throws a particular exception." The () => DoSomething() syntax represents a lambda, essentially an anonymous method. So in this case, we are telling Assert.Throws to execute the snippet o.Foo().
So no, you don't just add a single line like you do an attribute; you need to explicitly wrap the section of your test that will throw the exception, in a call to Assert.Throws. You don't necessarily have to use a lambda, but that's often the most convenient.
Here's a simple example using both ways.
string test = null;
Assert.Throws( typeof( NullReferenceException ), () => test.Substring( 0, 4 ) );
Assert.Throws<NullReferenceException>( () => test.Substring( 0, 4 ) );
If you don't want to use lambdas.
[Test]
public void Test()
{
Assert.Throws<NullReferenceException>( _TestBody );
}
private void _TestBody()
{
string test = null;
test.Substring( 0, 4 );
}
By default, TeamCity uses NUnit 2.2.10, which doesn't have ExpectedException. Check the TeamCity "NUnit for NAnt" docs to see how to change it to something more modern, including the specific list of releases TeamCity provides.
NUnit has added a new Record.Exception method.
If you prefer to separate Acts and Asserts then
Act:
ex = Record.Exception(()={throw new Exception()}
Assert:
Assert.NotNull(ex);
In Nunit2 i had a test like
[Test, ExpectedException(typeof(NullReferenceException))]
public void NullString()
{
secToken = new SecurityToken(null);
secToken.user.Should().BeNull();
secToken.pass.Should().BeNull();
secToken.ip.Should().BeNull();
}
How to rewrite it in Nunit3? I just can't handle it...
Suggest using Assert.Throws, example:
Assert.Throws<NullReferenceException>(() => secToken = new SecurityToken(null))
It is a closer scoping of the lines under test rather than just saying 'I think something in the test will throw'.
It also allows you to continue with the lines below, and returns the exception that was thrown.
First, I think the test is a bit unclear. Where do you expect the exception to occur? In the constructor? If it should be thrown there, why bother checking values on the constructed object?
Second, I would follow Lepijohnny's suggestion and follow the NUnit 3 style using the "constraint model".
Something like:
[Test]
public void NullString()
{
Assert.That(() => new SecurityToken(null), Throws.Exception.TypeOf<NullReferenceException>());
}
I am writing some unit tests using Visual Studio's integrated framework. I need to write some test cases which pass when a proper exception is thrown. The problem is that the exceptions i need to test for are inner exceptions nested in a more general one. Is there some easy solution or do I need to extend the whole functionality. I am currently using the [ExpectedException] attribute, but it wont do much good in such a situation.
I am also curious what happens when we use [ExpectedException] while we also have some Assert logic in the test itself. Are both the conditions evaluated(exception was thrown and the Assert statement turned out to be valid) or the test passes immediately after the correct exception is thrown?
Not a total solution, but in NUnit, you can do this sort of thing:
var ex = Assert.Throws<Exception>(() => thing.ThatThrows());
Assert.That(ex.InnerException, Is.TypeOf<BadException>() );
Maybe you can in your test framework?
If your framework doesn't support custom throwing, you usually have two choices:
Implement it yourself
Change (or extend) framework
I'll start with second solution. Consider using FluentAssertions library. It allows you to do something like this:
Action deleteUser = () => usersRepository.Delete(new User { Id = null });
deleteUser
.ShouldThrow<UserNotFoundException>()
.WithInnerException<ArgumentNullException>()
.WithInnerMessage("User Id must have value");
You will still use Visual Studio testing framework, just that you'll have one extra library for, well - fluent assertions.
First choice on the other hand is a bit more work as it is usually the case with hand-rolled solutions:
try
{
usersRepository.Delete(new User { Id = null });
Assert.Fail("Deleting user with null id should throw");
}
catch (UserNotFoundException ue)
{
Assert.AreEqual(ue.InnerException.Message, "User Id must have value");
}
You replace ExpectedException attribute with custom code asserting actual exception instance. Like I said, it is more work but does the trick.
this is an old question but i want to share my own implementation of ExpectedInnerExceptionAttribute with you guys. maybe useful for someone
public class ExpectedInnerExceptionAttribute : ExpectedExceptionBaseAttribute
{
public ExpectedInnerExceptionAttribute(Type exceptionType)
{
this.ExceptionType = exceptionType;
}
public Type ExceptionType { get; private set; }
protected override void Verify(Exception ex)
{
if (ex != null && ex.InnerException != null
&& ex.InnerException.GetType() == this.ExceptionType)
{
return;
}
throw ex;
}
}
You could also extend it to check exception message etc. you just need to add Your own logic in Verify method.
For unit testing i currently use FluentAssertions. Since i learned it i never wanted to assert stuff in any other way.
For asserting exceptions look at this bit of the documentation
In particular this part
Action act = () => subject.Foo2("Hello");
act.ShouldThrow<InvalidOperationException>()
.WithInnerException<ArgumentException>()
.WithInnerMessage("whatever")
FluentAssertions is really helpful.
and I achieved my solution using it as given below. This is checking my custom exception ProcessFailureException from AggregateException
Func<Task> func = async () => await item.ProcessAsync(context, message);
func.Should().Throw<AggregateException>().WithInnerException<ProcessFailureException>();
Just use GetAwaiter() and GetResult() to check for inner exception:
Assert.Throws<InnerException>(() => thing.GetAwaiter().GetResult());
e.g.
Assert.Throws<CommunicationException>(() => thing.GetAwaiter().GetResult());
I'm writing a unit test for this one method which returns "void". I would like to have one case that the test passes when there is no exception thrown. How do I write that in C#?
Assert.IsTrue(????)
(My guess is this is how I should check, but what goes into "???")
I hope my question is clear enough.
Your unit test will fail anyway if an exception is thrown - you don't need to put in a special assert.
This is one of the few scenarios where you will see unit tests with no assertions at all - the test will implicitly fail if an exception is raised.
However, if you really did want to write an assertion for this - perhaps to be able to catch the exception and report "expected no exception but got this...", you can do this:
[Test]
public void TestNoExceptionIsThrownByMethodUnderTest()
{
var myObject = new MyObject();
try
{
myObject.MethodUnderTest();
}
catch (Exception ex)
{
Assert.Fail("Expected no exception, but got: " + ex.Message);
}
}
(the above is an example for NUnit, but the same holds true for MSTest)
In NUnit, you can use:
Assert.DoesNotThrow(<expression>);
to assert that your code does not throw an exception. Although the test would fail if an exception is thrown even if there was no Assert around it, the value of this approach is that you can then distinguish between unmet expectations and bugs in your tests, and you have the option of adding a custom message that will be displayed in your test output. A well-worded test output can help you locate errors in your code that have caused a test to fail.
I think it's valid to add tests to ensure that your code is not throwing exceptions; for example, imagine you are validating input and need to convert an incoming string to a long. There may be occasions when the string is null, and this is acceptable, so you want to ensure that the string conversion does not throw an exception. There will therefore be code to handle this occasion, and if you haven't written a test for it you will be missing coverage around an important piece of logic.
This helper class scratched my itch with MSTest. Maybe it can scratch yours also.
[TestMethod]
public void ScheduleItsIneligibilityJob_HasValid_CronSchedule()
{
// Arrange
var factory = new StdSchedulerFactory();
IScheduler scheduler = factory.GetScheduler();
// Assert
AssertEx.NoExceptionThrown<FormatException>(() =>
// Act
_service.ScheduleJob(scheduler)
);
}
public sealed class AssertEx
{
public static void NoExceptionThrown<T>(Action a) where T:Exception
{
try
{
a();
}
catch (T)
{
Assert.Fail("Expected no {0} to be thrown", typeof(T).Name);
}
}
}
Don't test that something doesn't happen. It's like assuring that code doesn't break. That's sort of implied, we all strive for non-breaking, bug-less code. You want to write tests for that? Why just one method? Don't you want all your methods being tested that they don't throw some exception? Following that road, you'll end up with one extra, dummy, assert-less test for every method in your code base. It brings no value.
Of course, if your requirement is to verify method does catch exceptions, you do test that (or reversing it a bit; test that it does not throw what it is supposed to catch).
However, the general approach/practices remain intact - you don't write tests for some artificial/vague requirements that are out of scope of tested code (and testing that "it works" or "doesn't throw" is usually an example of such - especially in scenario when method's responsibilities are well known).
To put it simple - focus on what your code has to do and test for that.
I like to see an Assert.Whatever at the end of each test, just for consistency... without one, can I really be sure there's not supposed to be one there?
For me, this is as simple as putting Assert.IsTrue(true);
I know I didn't accidentally put that code in there, and thus I should be confident enough at quick a skim through that this was as intended.
[TestMethod]
public void ProjectRejectsGappedVersioningByDefault() {
var files = new List<ScriptFile>();
files.Add(ScriptProjectTestMocks.GetVersion1to2());
files.Add(ScriptProjectTestMocks.GetVersion3to4());
Assert.Throws<ScriptProject.InvalidProjectFormatException>(() => {
var sut = new ScriptProject(files);
});
}
[TestMethod]
public void ProjectAcceptsGappedVersionsExplicitly() {
var files = new List<ScriptFile>();
files.Add(ScriptProjectTestMocks.GetVersion1to2());
files.Add(ScriptProjectTestMocks.GetVersion3to4());
var sut = new ScriptProject(files, true);
Assert.IsTrue(true); // Assert.Pass() would be nicer... build it in if you like
}
My friend Tim told me about ExpectedException. I really like this b/c it is more succinct, less code, and very explicit that you are testing for an exception.
[TestMethod()]
[ExpectedException(typeof(System.Exception))]
public void DivideTest()
{
int numerator = 4;
int denominator = 0;
int actual = numerator / denominator;
}
You can read way more about it here: ExpectedException Attribute Usage.
With Xunit you can use this:
var exception = Record.Exception(() =>
MethodUnderTest());
Assert.Null(exception);
or for async operations
var exception = await Record.ExceptionAsync(async () =>
await MethodUnderTestAsync());
Assert.Null(exception);
Another way which worked for me is to store it in a variable and check output.
var result = service.Run()
Assert.IsFalse(result.Errors.Any())
using Moq;
using Xunit;
[Fact]
public void UnitTest_DoesNotThrow_Exception()
{
var builder = new Mock<ISomething>().Object;
//Act
var exception = Record.Exception(() => builder.SomeMethod());
//Assert
Assert.Null(exception);
}
I've got a set of test cases, some of which are expected to throw exceptions. Because of this, I have have set the attributes for these tests to expect exceptions like so:
[ExpectedException("System.NullReferenceException")]
When I run my tests locally all is good. However when I move my tests over to the CI server running TeamCity, all my tests that have expected exceptions fail. This is a known bug.
I am aware that there is also the Assert.Throws<> and Assert.Throws methods that NUnit offers.
My question is how can I make use of these instead of the attribute I'm currently using?
I've had a look around StackOverflow and tried a few things none of which seem to work for me.
Is there a simple 1 line solution to using this?
I'm not sure what you've tried that is giving you trouble, but you can simply pass in a lambda as the first argument to Assert.Throws. Here's one from one of my tests that passes:
Assert.Throws<ArgumentException>(() => pointStore.Store(new[] { firstPoint }));
Okay, that example may have been a little verbose. Suppose I had a test
[Test]
[ExpectedException("System.NullReferenceException")]
public void TestFoo()
{
MyObject o = null;
o.Foo();
}
which would pass normally because o.Foo() would raise a null reference exception.
You then would drop the ExpectedException attribute and wrap your call to o.Foo() in an Assert.Throws.
[Test]
public void TestFoo()
{
MyObject o = null;
Assert.Throws<NullReferenceException>(() => o.Foo());
}
Assert.Throws "attempts to invoke a code snippet, represented as a delegate, in order to verify that it throws a particular exception." The () => DoSomething() syntax represents a lambda, essentially an anonymous method. So in this case, we are telling Assert.Throws to execute the snippet o.Foo().
So no, you don't just add a single line like you do an attribute; you need to explicitly wrap the section of your test that will throw the exception, in a call to Assert.Throws. You don't necessarily have to use a lambda, but that's often the most convenient.
Here's a simple example using both ways.
string test = null;
Assert.Throws( typeof( NullReferenceException ), () => test.Substring( 0, 4 ) );
Assert.Throws<NullReferenceException>( () => test.Substring( 0, 4 ) );
If you don't want to use lambdas.
[Test]
public void Test()
{
Assert.Throws<NullReferenceException>( _TestBody );
}
private void _TestBody()
{
string test = null;
test.Substring( 0, 4 );
}
By default, TeamCity uses NUnit 2.2.10, which doesn't have ExpectedException. Check the TeamCity "NUnit for NAnt" docs to see how to change it to something more modern, including the specific list of releases TeamCity provides.
NUnit has added a new Record.Exception method.
If you prefer to separate Acts and Asserts then
Act:
ex = Record.Exception(()={throw new Exception()}
Assert:
Assert.NotNull(ex);