There are two mayor news:
- the Executing static class
- the Executing extension
The Executing static class
It is the replacement of the previous ActionAssert static class that now is marked as obsolete and will be removed after final release of 1.0.0.The difference with ActionAssert will be more clear seeing the implementation of the new class:
public static class Executing { public static Action This(Action action) { return action; } }
As you can see it is a simple and real short-cut for Actions Assertion.
This class is particularly useful to test constructors:
Executing.This(() => new AClass(null)).Should().Throw<ArgumentNullException>();
and obviously with chains:
Executing.This(() => new AClass(null)).Should().Throw<ArgumentNullException>() .And.ValueOf .ParamName.Should().Be("obj");
The Executing extension
Working with Sharp Tests Ex I have noticed how much difficult is leave the fluent-assertion and go back to a static Assert. Previous to 1.0.0RC2 the only way to create an Assert for a method execution was through ActionAssert and each time I have used it I felt a strange sensation. To fix the problem here come the Executing extension.
Given a class like this:
public class MyClass { public void DoSomething(string value) { if (value == null) { throw new ArgumentNullException("value","My message"); } } }
the tests of the method may look like:
var myClass = new MyClass(); myClass.Executing(a => a.DoSomething(null)).Throws<ArgumentNullException>(); myClass.Executing(a => a.DoSomething("somethig")).NotThrows();
and even in this case you can use chains as usual:
myClass.Executing(a => a.DoSomething(null)).Throws<ArgumentNullException>() .Exception.Satisfy(ex => ex.ParamName == "value" && ex.Message.Contains("My message"));
Enjoy the new release downloading it !
What about DoesNotThrow instead of NotThrows like in xUnit?
ReplyDeleteIt is already there:
ReplyDeletehttp://sharptestex.codeplex.com/sourcecontrol/network/Show?projectName=SharpTestEx&changeSetId=45173#721561
You mean NotThrows is already there?
ReplyDeleteI know but i think that Executing(...).DoesNotThrow is more 'fluent' or nicer speaking then Executing(...).NotThrows.
It's just a detail. I love the framework. Already using it full time.
Keep up the good work!