Quantcast
Channel: Fluent Assertions
Viewing all 1402 articles
Browse latest View live

Updated Wiki: Documentation

$
0
0

Supported Test Frameworks

Fluent Assertions supports MSTest, NUnit and XUnit. Starting with version 1.3.0, you can simply add a reference to the corresponding test framework assembly to the unit test project. Fluent Assertions will automatically find the corresponding assembly and use it for throwing the framework-specific exceptions. If, for some unknown reason, Fluent Assertions fails to find the assembly, try specifying the framework explicitly using a configuration setting in the project’s app.config.

<configuration>    
  <appSettings>    
    <!-- Supported values: nunit, xunit and mstest -->
    <add key="FluentAssertions.TestFramework" value="nunit"/>
  </appSettings>
</configuration>

Reference Types

object theObject = null;
theObject.Should().BeNull("because the value is null");
     
theObject = "whatever";
theObject.Should().BeOfType<String>("because a {0} is set", typeof(String));
theObject.Should().NotBeNull();

string otherObject = "whatever";
theObject.Should().Be(otherObject, "because they have the same values");
     
theObject = otherObject;     
theObject.Should().BeSameAs(otherObject);
theObject.Should().NotBeSameAs(otherObject);

var ex = new ArgumentException();
ex.Should().BeAssignableTo<Exception>("because it is an exception");

var dummy = new Object();
dummy.Should().Match(d => (d.ToString() == "System.Object"));
dummy.Should().Match<string>(d => (d == "System.Object"));
dummy.Should().Match((string d) => (d == "System.Object"));

Some users requested the ability to easily downcast an object to one of its derived classes in a fluent way.

customer.Animals.First().As<Human>().Height.Should().Be(178);

Booleans

bool theBoolean = false;
theBoolean.Should().BeFalse("it's set to false");

theBoolean = true;
theBoolean.Should().BeTrue();
theBoolean.Should().Be(otherBoolean);

Strings

string theString = "";
theString.Should().BeEmpty();
theString.Should().NotBeEmpty("because the string is not empty"); 
theString.Should().HaveLength(0);

theString = "This is a String";
theString.Should().NotBeNull();
theString.Should().Be("This is a String");
theString.Should().NotBe("This is another String");
theString.Should().BeEquivalentTo("THIS IS A STRING");
theString.Should().EndWith("a String");
theString.Should().EndWithEquivalent("a string");
theString.Should().Contain("is a");
theString.Should().StartWith("This");
theString.Should().StartWithEquivalent("this");

string theString = null;
theString.Should().BeNull();

Integers, singles, doubles, decimals and everything else that implements IComparable

int theInt = 5;
theInt.Should().BeGreaterOrEqualTo(5);
theInt.Should().BeGreaterOrEqualTo(3);
theInt.Should().BeGreaterThan(4);     
theInt.Should().BeLessOrEqualTo(5);
theInt.Should().BeLessThan(6);
theInt.Should().BePositive();
theInt.Should().Be(5);
theInt.Should().NotBe(10);
theInt.Should().BeInRange(1,10); theInt = -8; theInt.Should().BeNegative(); double theDouble = 5.1; theDouble.Should().BeGreaterThan(5);
byte theByte = 2;
theByte.Should().Be(2);

short? theShort = null;
theShort.Should().NotHaveValue();

int? theInt = 3;
theInt.Should().HaveValue();

Notice that Should().Be() and Should().NotBe() are not available for floats and doubles. As explained in this article, floating point variables are inheritably inaccurate and should never be compared for equality. Instead, either use the Should().BeInRange() method or the following method specifically designed for floating point variables.

float value = 3.1415927F;
value.Should().BeApproximately(3.14F, 0.001F);

This will verify that the value of the float is between 3.139 and 3.141.

Dates, times and time spans

var theDatetime = new Datetime(2010, 3, 1, 22, 15, 0);

theDatetime.Should().BeAfter(new Datetime(2010, 2, 1));
theDatetime.Should().BeBefore(new Datetime(2010, 3, 2));     
theDatetime.Should().BeOnOrAfter(new Datetime(2010, 3, 1));

theDatetime.Should().Be(new Datetime(2010, 3, 1, 22, 15, 0));

theDatetime.Should().HaveDay(1);
theDatetime.Should().HaveMonth(3);
theDatetime.Should().HaveYear(2010);
theDatetime.Should().HaveHour(22);
theDatetime.Should().HaveMinute(15);
theDatetime.Should().HaveSecond(0);

In version 1.2 I've added a whole set of methods for asserting that the difference between two DateTime objects match a certain time frame. All five methods support a Before and After extension method. With version 1.4, you no longer have to use the TimeSpan class directly and instead use extension methods to convert a number to a TimeSpan.

theDatetime.Should().BeLessThan(10.Minutes()).Before(otherDatetime); // Equivalent to <
theDatetime.Should().BeWithin(2.Hours()).After(otherDatetime);       // Equivalent to <=
theDatetime.Should().BeMoreThan(1.Days()).Before(deadline);          // Equivalent to >
theDatetime.Should().BeAtLeast(2.Days()).Before(deliveryDate);       // Equivalent to >=
theDatetime.Should().BeExactly(24.Hours()).Before(appointement);     // Equivalent to ==

Version 1.4 introduces dedicated methods that apply to TimeSpans directly:

var timespan = new Timespan(12, 59, 59); 
timespan.Should().BePositive(); 
timespan.Should().BeNegative(); 
timespan.Should().Be(12.Hours()); 
timespan.Should().NotBe(1.Days()); 
timespan.Should().BeLessThan(someOtherTimespan); 
timespan.Should().BeLessOrEqual(someOtherTimespan); 
timespan.Should().BeGreaterThan(someOtherTimespan); 
timespan.Should().BeGreaterOrEqual(someOtherTimespan);

Collections

IEnumerable collection = new[] { 1, 2, 5, 8 };

collection.Should().NotBeEmpty()
     .And.HaveCount(4)
     .And.ContainInOrder(new[] { 2, 5 })
     .And.ContainItemsAssignableTto<int>();

collection.Should().Equal(new list<int> { 1, 2, 5, 8 });
collection.Should().Equal(1, 2, 5, 8);
collection.Should().BeEquivalent(8, 2, 1, 5);
collection.Should().NotBeEquivalent(8, 2, 3, 5);


collection.Should().HaveCount(c => c > 3).And.OnlyHaveUniqueItems();
collection.Should().HaveSameCount(new[] {6, 2, 0, 5});

collection.Should().BeSubsetOf(new[] { 1, 2, 3, 4, 5, 6, 7, 8, 9, });
collection.Should().Contain(8).And.HaveElementAt(2, 5).And.NotBeSubsetOf(new[] {11, 56});
collection.Should().Contain(x => x > 3);
collection.Should().Contain(collection, 5, 6); // It should contain the original items, plus 5 and 6. collection.Should().OnlyContain(x => x < 10); collection.Should().OnlyContainItemsOfType<int>(); collection.Should().NotContain(82); collection.Should().NotContainNulls();
collection.Should().NotContain(x => x > 10); collection = new int[0]; collection.Should().BeEmpty();

Exceptions

The following example verifies that the Foo() method throws an InvalidOperationException which Message property has a specific value.

subject.Invoking(y => y.Foo("Hello"))
     .ShouldThrow<InvalidOperationException>()
     .WithMessage("Hello is not allowed at this moment”);

But if you, like me, prefer the arrange-act-assert syntax, you can also use an action in your act part.

Action act = () => subject.Foo2("Hello");
Act.ShouldThrow<InvalidOperationException>() .WithInnerException<ArgumentException>() .WithInnerMessage("whatever");

Notice that the example also verifies that the exception has a particular inner exception with a specific message. in fact, you can even check the individual properties of the exception instance using the And property.

Action act = () => subject.Foo(null));
act.ShouldThrow<ArgumentNullException>() .And.ParamName.Should().Equal("message");

An alternative syntax for doing the same is by chaining or more calls to the Where() method introduced in version 1.4.0:

Action act = () => subject.Foo(null));

act.ShouldThrow<ArgumentNullException>().Where(e => e.Message.StartsWith(“did”));

If the method you are testing returns an IEnumerable or IEnumerable<T> and it uses the yield keyword to construct that collection, just calling the method will not cause the effect you expected. Because the real work is not done until you actually iterate over that collection. you can use the Enumerating() extension method to force enumerating the collection like this.

Func<IEnumerable<char>> func = () => obj.SomeMethodThatUsesYield("blah");
func.Enumerating().ShouldThrow<ArgumentException>();

You do have to use the Func<T> type instead of Action<T> then.

On the other hand, you may want to verify that no exceptions were thrown.

Action act = () => subject.Foo("Hello"));
act.ShouldNotThrow();

I know that a unit test will fail anyhow if an exception was thrown, but this syntax returns a clearer description of the exception that was thrown and fits better to the AAA syntax.

If you want to verify that a specific exception is not thrown, and want to ignore others, you can do that using an overload:

Action act = () => subject.Foo("Hello"));
act.ShouldNotThrow<InvalidOperationException>();

Property Comparison

You can assert the equality of entire objects by comparing their properties by name. This even works if the types of the properties differ but a built-in conversion exists (through the Convert class). As an example, consider a Customer entity from some arbitrary domain model and its DTO counterpart CustomerDto. You can assert that the DTO has the same values as the entity using this syntax:

dto.ShouldHave().AllProperties().EqualTo(customer);

As long as all properties of dto are also available on customer, and their value is equal or convertible, the assertion succeeds. You can, however, exclude a specific property using a property expression, such as for instance the ID property:

dto.ShouldHave().AllPropertiesBut(d => d.Id).EqualTo(customer);

Which is equivalent to:

dto.ShouldHave().AllProperties().But(d => d.Id).EqualTo(customer);

The other way around is also possible. So if you only want to include two specific properties, use this syntax.

dto.ShouldHave().Properties(d => d.Name, d => d.Address).EqualTo(customer);

And finally, if you only want to compare the properties that both objects have, you can use the SharedProperties() method like this:

dto.ShouldHave().SharedProperties().EqualTo(customer);

Obviously, you can chain that with a But() method to exclude some of the shared properties.

Event Monitoring

Version 1.3.0 introduces a new set of extensions that allow you to verify that an object raised a particular event. Before you can invoke the assertion extensions, you must first tell Fluent Assertions that you want to monitor the object:

var subject = new EditCustomerViewModel();
subject.MonitorEvents();

Assuming that we’re dealing with a MVVM implementation, you might want to verify that it raised its PropertyChanged event for a particular property:

subject
  .ShouldRaise("PropertyChanged")
.WithSender(subject) .WithArgs<PropertyChangedEventArgs>(args => args.PropertyName == "SomeProperty");

Notice that WithSender() verifies that all occurrences had its sender argument set to the specified object. WithArgs() just verifies that at least one occurrence had a matching EventArgs object. In other words, event monitoring only works for events that comply with the standard two-argument sender/args .NET pattern.

Since verifying for PropertyChanged events is so common, I’ve included a specialized shortcut to the example above:

subject.ShouldRaisePropertyChangeFor(x => x.SomeProperty);

In version 1.4 you can also do the opposite; asserting that a particular event was not raised.

subject.ShouldNotRaisePropertyChangeFor(x => x.SomeProperty);

Or, if your project is .NET 3.5 or 4.0 based:

subject.ShouldNotRaise(“SomeOtherEvent”);

Important Limitation: Due to limitations in Silverlight, only the ShouldRaisePropertyChangeFor() and ShouldNotRaisePropertyChangeFor() methods are supported in the Silverlight version of Fluent Assertions.

Execution Time

New in version 1.4 is a method to assert that the execution time of particular method or action does not exceed a predefined value. To verify the execution time of a method, use the following syntax:

var subject = new SomePotentiallyVerySlowClass();
subject.ExecutionTimeOf(s => s.ExpensiveMethod()).ShouldNotExceed(500.Milliseconds());

Alternatively, to verify the execution time of an arbitrary action, use this syntax:

Action someAction = () => Thread.Sleep(510);
someAction.ExecutionTime().ShouldNotExceed(100.Milliseconds());

Since it doesn’t make sense to do something like that in Silverlight, it is only available in the .NET 3.5 and .NET 4.0 versions of Fluent Assertions.

Extensibility

Adding your own assertion extensions is quite straightforward and happens in my projects quite often. You have a few options though.

  • Extend one of the built-in classes such as CollectionAssertions<T>or ReferenceTypeAssertions<T> and expose them through a custom static class with extension methods named Should().
  • Create extension methods that extend an assertion class:
public static void BeWhatever<T>(this GenericCollectionAssertions<T> assertions)
{ 
  if (assertions.Subject != ...) 
  { 
     Verification.Fail("Expected whatever..."); 
  }
}
  • Create a custom assertions class and use the Verification class to verify conditions and create comprehensive failure messages using the built-in formatters.

Created Release: Release 1.4.0

$
0
0
News
  • Added methods for asserting that a value is within a range.
  • Added dedicated methods for asserting floating point values against an approximate value.
  • Added support for asserting the execution time of a class member or an action (only for .NET 3.5 and 4.0)
  • Added support for assertions on TimeSpans, including converting a number of seconds to a TimeSpan, all contributed by Ruben Rorije.
  • Added the possibility to add an extra condition to exception assertions using the .Where(x => condition) extension method.
  • Added support for ShouldNotRaise() and ShouldNotRaisePropertyChangedFor().
  • Added extension methods to convert numbers to minutes, hours and days.
  • Added support for numeric assertions on (nullable) bytes and shorts.

Changes/improvements
  • Moved the assertion classes to a dedicated project folder (and thus a different namespace)
  • Introduced a more fluent mechanism for verifying an internal conditions.

For a more in-depth discussion of the new functionality:
http://www.dennisdoomen.net/2011/02/another-release-for-fluent-assertions.html

Updated Release: Release 1.4.0

$
0
0
News
  • Added methods for asserting that a value is within a range.
  • Added dedicated methods for asserting floating point values against an approximate value.
  • Added support for asserting the execution time of a class member or an action (only for .NET 3.5 and 4.0)
  • Added support for assertions on TimeSpans, including converting a number of seconds to a TimeSpan, all contributed by Ruben Rorije.
  • Added the possibility to add an extra condition to exception assertions using the .Where(x => condition) extension method.
  • Added support for ShouldNotRaise() and ShouldNotRaisePropertyChangedFor().
  • Added extension methods to convert numbers to minutes, hours and days.
  • Added support for numeric assertions on (nullable) bytes and shorts.

Changes/improvements
  • Moved the assertion classes to a dedicated project folder (and thus a different namespace)
  • Introduced a more fluent mechanism for verifying an internal conditions.

For a more in-depth discussion of the new functionality:
http://www.dennisdoomen.net/2011/02/another-release-for-fluent-assertions.html

Released: Release 1.4.0 (Feb 27, 2011)

$
0
0
News
  • Added methods for asserting that a value is within a range.
  • Added dedicated methods for asserting floating point values against an approximate value.
  • Added support for asserting the execution time of a class member or an action (only for .NET 3.5 and 4.0)
  • Added support for assertions on TimeSpans, including converting a number of seconds to a TimeSpan, all contributed by Ruben Rorije.
  • Added the possibility to add an extra condition to exception assertions using the .Where(x => condition) extension method.
  • Added support for ShouldNotRaise() and ShouldNotRaisePropertyChangedFor().
  • Added extension methods to convert numbers to minutes, hours and days.
  • Added support for numeric assertions on (nullable) bytes and shorts.

Changes/improvements
  • Moved the assertion classes to a dedicated project folder (and thus a different namespace)
  • Introduced a more fluent mechanism for verifying an internal conditions.

For a more in-depth discussion of the new functionality:
http://www.dennisdoomen.net/2011/02/another-release-for-fluent-assertions.html

Updated Release: Release 1.4.0 (Feb 27, 2011)

$
0
0
News
  • Added methods for asserting that a value is within a range.
  • Added dedicated methods for asserting floating point values against an approximate value.
  • Added support for asserting the execution time of a class member or an action (only for .NET 3.5 and 4.0)
  • Added support for assertions on TimeSpans, including converting a number of seconds to a TimeSpan, all contributed by Ruben Rorije.
  • Added the possibility to add an extra condition to exception assertions using the .Where(x => condition) extension method.
  • Added support for ShouldNotRaise() and ShouldNotRaisePropertyChangedFor().
  • Added extension methods to convert numbers to minutes, hours and days.
  • Added support for numeric assertions on (nullable) bytes and shorts.

Changes/improvements
  • Moved the assertion classes to a dedicated project folder (and thus a different namespace)
  • Introduced a more fluent mechanism for verifying an internal conditions.

For a more in-depth discussion of the new functionality:
http://www.dennisdoomen.net/2011/02/another-release-for-fluent-assertions.html

Source code checked in, #62929

$
0
0
Updated to the latest NuGet packager

Source code checked in, #62939

$
0
0
Replaced Rhino Mocks with FakeItEasy. Added all existing specs to run under Silverlight as well.

Updated Wiki: Home

$
0
0

Project Description

Fluent Assertions is a set of .NET extension methods that allow you to more naturally specify the expected outcome of a TDD or BDD-style test. We currently use it in all our internal and client projects, and it is even used in the NCQRS project.

Why another framework?

We primarily use Visual Studio 2010’s own testing framework and were not satisfied by other similar frameworks. The best one we ran into missed a nice natural way for specifying the reason that is displayed when an assertion failed. Moreover, we like to be able to easily add domain-specific assertions without having to subclass a whole bunch of obscure interfaces and abstract classes. In the beginning of 2010, after having used the framework internally for almost a year, we decided to make it public and rebrand it as Fluent Assertions.

Example

// Verifying that a string begins, ends and contains a particular phrase.
string actual = "ABCDEFGHI";
actual.Should().StartWith("AB").And.EndWith("HI").And.Contain("EF").And.HaveLength(9);

// Verifying that the collection contains a specified number of elements
// and that all elements match a predicate.
IEnumerable collection = new[] { 1, 2, 3 }; collection.Should().HaveCount(4, "because we thought we put three items in the collection"))
collection.Should().Contain(i => i > 0); // Verifying that a particular business rule is enforced using exceptions. var recipe = new RecipeBuilder() .With(new IngredientBuilder().For("Milk").WithQuantity(200, Unit.Milliliters)) .Build(); Action action = () => recipe.AddIngredient("Milk", 100, Unit.Spoon); action .ShouldThrow<RuleViolationException>() .WithMessage("Cannot change the unit of an existing ingredient") .And.Violations.Should().Contain(BusinessRule.CannotChangeIngredientQuanity);
The nice thing about the second failing example is that it will throw an exception with the message

"Expected <4> items because we thought we put three items in the collection, but found <3>."

This should keep you from having to start the debugger to figure out what went wrong. This is one of the fundamental principles we think Fluent Assertions should help you with. Note that you don't need to include the word because explicitly. The framework will prepend your phrase with it automatically.

News

February 27th, 2011
Another update with lots of community requests. Read more about it over here.
January 15th, 2011
You can now download the latest version directly from within Visual Studio by using the NuGet package manager.
 
January 1st, 2011
Fluent Assertions 1.3.0 has been released with many improvements, event monitoring extensions and strong naming. More importantly, it is no longer linked to a particular version of NUnit, XUnit or MSTest.
 
August 27th, 2010
Fluent Assertions 1.2.3 has been released. It's another small release with some minor additions and bug fixes.  
 
June 29th, 2010
Fluent Assertions 1.2.2 has been released. It's a small release to fix some issues. Read more about it here

May 12th, 2010
Small release to fix an issue with enumerables that use the yield keyword. Now includes separate assemblies for different unit testing frameworks, including NUnit 2.5.5.10112.

April 12th, 2010
Fluent Assertions 1.2 has been released. Read more about it here

March 5th, 2010
We've worked hard to add some important missing features that we really needed, and also improve resilience against illegal arguments such as an empty collection or null. You can find it here: Fluent Assertions release 1.1.

Who are we?

We are a bunch of developers working for Aviva Solutions who highly value software quality, in particular

Created Issue: Null to null comparison bug. [10262]

$
0
0
string actual = null;
string expected = null;
actual.Should().Be(expected); // BUG: Expected <null>, but found <null>.

Reviewed: Release 1.4.0 (Feb 28, 2011)

$
0
0
Rated 5 Stars (out of 5) - Just downloaded and updated our codebase to the newest version. Works great and makes our assertions a lot more readable. Tanks a lot for this great framework!

Updated Wiki: Home

$
0
0

Project Description

Fluent Assertions is a set of .NET extension methods that allow you to more naturally specify the expected outcome of a TDD or BDD-style test. We currently use it in all our internal and client projects, and it is even used in the NCQRS project.

Why another framework?

We primarily use Visual Studio 2010’s own testing framework and were not satisfied by other similar frameworks. The best one we ran into missed a nice natural way for specifying the reason that is displayed when an assertion failed. Moreover, we like to be able to easily add domain-specific assertions without having to subclass a whole bunch of obscure interfaces and abstract classes. In the beginning of 2010, after having used the framework internally for almost a year, we decided to make it public and rebrand it as Fluent Assertions.

Example

// Verifying that a string begins, ends and contains a particular phrase.
string actual = "ABCDEFGHI";
actual.Should().StartWith("AB").And.EndWith("HI").And.Contain("EF").And.HaveLength(9);

// Verifying that the collection contains a specified number of elements
// and that all elements match a predicate.
IEnumerable collection = new[] { 1, 2, 3 }; collection.Should().HaveCount(4, "because we thought we put three items in the collection"))
collection.Should().Contain(i => i > 0); // Verifying that a particular business rule is enforced using exceptions. var recipe = new RecipeBuilder() .With(new IngredientBuilder().For("Milk").WithQuantity(200, Unit.Milliliters)) .Build(); Action action = () => recipe.AddIngredient("Milk", 100, Unit.Spoon); action .ShouldThrow<RuleViolationException>() .WithMessage("Cannot change the unit of an existing ingredient") .And.Violations.Should().Contain(BusinessRule.CannotChangeIngredientQuanity);
The nice thing about the second failing example is that it will throw an exception with the message

"Expected <4> items because we thought we put three items in the collection, but found <3>."

This should keep you from having to start the debugger to figure out what went wrong. This is one of the fundamental principles we think Fluent Assertions should help you with. Note that you don't need to include the word because explicitly. The framework will prepend your phrase with it automatically.

News

February 27th, 2011
Another update with lots of community requests. Read more about it over here.
January 15th, 2011
You can now download the latest version directly from within Visual Studio by using the NuGet package manager.
 
January 1st, 2011
Fluent Assertions 1.3.0 has been released with many improvements, event monitoring extensions and strong naming. More importantly, it is no longer linked to a particular version of NUnit, XUnit or MSTest.
 
August 27th, 2010
Fluent Assertions 1.2.3 has been released. It's another small release with some minor additions and bug fixes.  
 
June 29th, 2010
Fluent Assertions 1.2.2 has been released. It's a small release to fix some issues. Read more about it here

May 12th, 2010
Small release to fix an issue with enumerables that use the yield keyword. Now includes separate assemblies for different unit testing frameworks, including NUnit 2.5.5.10112.

April 12th, 2010
Fluent Assertions 1.2 has been released. Read more about it here

March 5th, 2010
We've worked hard to add some important missing features that we really needed, and also improve resilience against illegal arguments such as an empty collection or null. You can find it here: Fluent Assertions release 1.1.

Who are we?

We are a bunch of developers working for Aviva Solutions who highly value software quality, in particular

Updated Wiki: Home

$
0
0

Project Description

Fluent Assertions is a set of .NET extension methods that allow you to more naturally specify the expected outcome of a TDD or BDD-style test. We currently use it in all our internal and client projects, and it is even used in the NCQRS project.

Why another framework?

We primarily use Visual Studio 2010’s own testing framework and were not satisfied by other similar frameworks. The best one we ran into missed a nice natural way for specifying the reason that is displayed when an assertion failed. Moreover, we like to be able to easily add domain-specific assertions without having to subclass a whole bunch of obscure interfaces and abstract classes. In the beginning of 2010, after having used the framework internally for almost a year, we decided to make it public and rebrand it as Fluent Assertions.

Example

// Verifying that a string begins, ends and contains a particular phrase.
string actual = "ABCDEFGHI";
actual.Should().StartWith("AB").And.EndWith("HI").And.Contain("EF").And.HaveLength(9);

// Verifying that the collection contains a specified number of elements
// and that all elements match a predicate.
IEnumerable collection = new[] { 1, 2, 3 }; collection.Should().HaveCount(4, "because we thought we put three items in the collection"))
collection.Should().Contain(i => i > 0); // Verifying that a particular business rule is enforced using exceptions. var recipe = new RecipeBuilder() .With(new IngredientBuilder().For("Milk").WithQuantity(200, Unit.Milliliters)) .Build(); Action action = () => recipe.AddIngredient("Milk", 100, Unit.Spoon); action .ShouldThrow<RuleViolationException>() .WithMessage("Cannot change the unit of an existing ingredient") .And.Violations.Should().Contain(BusinessRule.CannotChangeIngredientQuanity);
The nice thing about the second failing example is that it will throw an exception with the message

"Expected <4> items because we thought we put three items in the collection, but found <3>."

This should keep you from having to start the debugger to figure out what went wrong. This is one of the fundamental principles we think Fluent Assertions should help you with. Note that you don't need to include the word because explicitly. The framework will prepend your phrase with it automatically.

News

February 27th, 2011
Another update with lots of community requests. Read more about it over here.
January 15th, 2011
You can now download the latest version directly from within Visual Studio by using the NuGet package manager.
 
January 1st, 2011
Fluent Assertions 1.3.0 has been released with many improvements, event monitoring extensions and strong naming. More importantly, it is no longer linked to a particular version of NUnit, XUnit or MSTest.
 
August 27th, 2010
Fluent Assertions 1.2.3 has been released. It's another small release with some minor additions and bug fixes.  
 
June 29th, 2010
Fluent Assertions 1.2.2 has been released. It's a small release to fix some issues. Read more about it here

May 12th, 2010
Small release to fix an issue with enumerables that use the yield keyword. Now includes separate assemblies for different unit testing frameworks, including NUnit 2.5.5.10112.

April 12th, 2010
Fluent Assertions 1.2 has been released. Read more about it here

March 5th, 2010
We've worked hard to add some important missing features that we really needed, and also improve resilience against illegal arguments such as an empty collection or null. You can find it here: Fluent Assertions release 1.1.

Who are we?

We are a bunch of developers working for Aviva Solutions who highly value software quality, in particular

Created Issue: Should().NotBeEmpty() enumerates whole collection [10362]

$
0
0
I have a service that returns IEnumerable<T> one by one very slowly (or even returns stream that never ends).
I want to test that it actually returns something so I do

service.GetAll().Should().NotBeEmpty();

and it does not complete until it enumerates the whole result. I could do Take(1) but I would rather fix NotBeEmpty method if possible.

Created Issue: Should().NotBeEmpty() enumerates collection twice [10363]

$
0
0
I have a service that returns IEnumerable<T> and enumeration is fairly slow.
I am writing a smoke test that just makes sure something is returned:

service.GetAll().Should().NotBeEmpty();

I see that my collection gets enumerated twice (something I would not expect from such assertion).

This issue is tightly linked to http://fluentassertions.codeplex.com/workitem/10362

Commented Issue: Should().NotBeEmpty() enumerates whole collection [10362]

$
0
0
I have a service that returns IEnumerable<T> one by one very slowly (or even returns stream that never ends).
I want to test that it actually returns something so I do

service.GetAll().Should().NotBeEmpty();

and it does not complete until it enumerates the whole result. I could do Take(1) but I would rather fix NotBeEmpty method if possible.
Comments: ** Comment from web user: dennisdoomen **

That's why I introduced the Enumerating() extension method. It forces enumeration of the entire collection.


Commented Issue: Should().NotBeEmpty() enumerates collection twice [10363]

$
0
0
I have a service that returns IEnumerable<T> and enumeration is fairly slow.
I am writing a smoke test that just makes sure something is returned:

service.GetAll().Should().NotBeEmpty();

I see that my collection gets enumerated twice (something I would not expect from such assertion).

This issue is tightly linked to http://fluentassertions.codeplex.com/workitem/10362
Comments: ** Comment from web user: dennisdoomen **

You're right. That's because the CollectionAssertions.NotBeEmpty() is calling Count() twice (once for the actual check, and once for the failure message). I never considered performance a real issue. Do you have this problem because you're doing integration testing (e.g. calling something really expensive)?

Commented Issue: Should().NotBeEmpty() enumerates collection twice [10363]

$
0
0
I have a service that returns IEnumerable<T> and enumeration is fairly slow.
I am writing a smoke test that just makes sure something is returned:

service.GetAll().Should().NotBeEmpty();

I see that my collection gets enumerated twice (something I would not expect from such assertion).

This issue is tightly linked to http://fluentassertions.codeplex.com/workitem/10362
Comments: ** Comment from web user: MatFiz **

Yes, I'm doing integration testing (actually it's smoke testing) and I would prefer it to run as fast as possible.

Commented Issue: Should().NotBeEmpty() enumerates whole collection [10362]

$
0
0
I have a service that returns IEnumerable<T> one by one very slowly (or even returns stream that never ends).
I want to test that it actually returns something so I do

service.GetAll().Should().NotBeEmpty();

and it does not complete until it enumerates the whole result. I could do Take(1) but I would rather fix NotBeEmpty method if possible.
Comments: ** Comment from web user: MatFiz **

Could you clarify?
I want the opposite - do not enumerate the whole collection. You just need to try and get one element in order to understand if the collection is empty or not.

Commented Issue: Should().NotBeEmpty() enumerates whole collection [10362]

$
0
0
I have a service that returns IEnumerable<T> one by one very slowly (or even returns stream that never ends).
I want to test that it actually returns something so I do

service.GetAll().Should().NotBeEmpty();

and it does not complete until it enumerates the whole result. I could do Take(1) but I would rather fix NotBeEmpty method if possible.
Comments: ** Comment from web user: dennisdoomen **

It was originally introduced to force enumerating a collection that uses the yield keyword. But in your case it's best if I change the NotBeEmpty() to use the Any() keyword.

New Post: Floating point precision

$
0
0

Hi Dennis,

I was having a look at your 1.4.0 release (as documented on your blog), but cannot find the BeApproximately method that you refer to. The Be method has indeed gone, but I can't find its replacement; I've had a peek in the source code for NumericAssertions, and it's not there either.

Viewing all 1402 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>