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

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 used in many open-source projects. It runs on .NET 3.5, 4.0 and 4.5 (Desktop and Windows Store), Silverlight 4 and 5 and Windows Phone 7.5. And it supports the unit test frameworks NUnit, XUnit, MBUnit, Gallio and MSpec.

Why?

Nothing is more annoying then a unit test that fails without clearly explaining why. More than often, you need to set a breakpoint and start up the debugger to be able to figure out what went wrong. Jeremy D. Miller once gave the advice to "keep out of the debugger hell" and I can only agree with that.

For instance, only test a single condition per test case. If you don't, and the first condition fails, the test engine will not even try to test the other conditions. But if any of the others fail, you'll be on your own to figure out which one. I often run into this problem when developers try to combine multiple related tests that test a member using different parameters into one test case. If you really need to do that, consider using aparameterized test that is being called by several clearly named test cases.

That’s why we designed Fluent Assertions to help you in this area. Not only by using clearly named assertion methods, but also by making sure the failure message provides as much information as possible. Consider this example:

"1234567890".Should().Be("0987654321");

This will be reported as:

clip_image001[6]

The fact that both strings are displayed on a separate line is on purpose and happens if any of them is longer than 8 characters. However, if that's not enough, all assertion methods take an optional formatted reason with placeholders, similarly to String.Format, that you can use to enrich the failure message. For instance, the assertion

new[] { 1, 2, 3 }.Should().Contain(item => item > 3, "at least {0} item should be larger than 3", 1);

will fail with:

clip_image002[6]

Examples

To verify 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);

To verify that a 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);
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>."

To verify 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("change the unit of an existing ingredient", ComparisonMode.Substring)
   .And.Violations.Should().Contain(BusinessRule.CannotChangeIngredientQuanity);

What’s new?

May 20th, 2013
@ 
 
March 3rd, 2013
We've released a small bugfix on Nuget and CodePlex.

 
October 7th, 2012
Version 2.0 is now out of beta.
August 25th, 2012
Fluent Assertions 2.0, a major new version with support for .NET 4.5, Windows Phone and Windows Store Apps is inbeta. Read all the details in this blog post.
  
January 13th, 2012
A relatively small release. Read all about it in this blog post.
 
October 31st, 2011
Another release with lots of bug fixes and small improvements and with great contributions by Martin Opdam and Urs Enzler. Download ithere or get it throughNuGet.
 

About versioning

The version numbers of Fluent Assertions releases comply to the Semantic Versioning scheme. In other words, release 1.4.0 only adds backwards-compatible functionality and bug fixes compared to 1.3.0. Release 1.4.1 should only include bug fixes. And if we ever introduce breaking changes, the number increased to 2.0.0.

Who are we?

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

If you have any comments or suggestions, please let us know via twitter, through thediscussions page, or throughStackOverflow.

clip_image002#fluentassertions

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 used in many open-source projects. It runs on .NET 3.5, 4.0 and 4.5 (Desktop and Windows Store), Silverlight 4 and 5 and Windows Phone 7.5. And it supports the unit test frameworks NUnit, XUnit, MBUnit, Gallio and MSpec.

Why?

Nothing is more annoying then a unit test that fails without clearly explaining why. More than often, you need to set a breakpoint and start up the debugger to be able to figure out what went wrong. Jeremy D. Miller once gave the advice to "keep out of the debugger hell" and I can only agree with that.

For instance, only test a single condition per test case. If you don't, and the first condition fails, the test engine will not even try to test the other conditions. But if any of the others fail, you'll be on your own to figure out which one. I often run into this problem when developers try to combine multiple related tests that test a member using different parameters into one test case. If you really need to do that, consider using aparameterized test that is being called by several clearly named test cases.

That’s why we designed Fluent Assertions to help you in this area. Not only by using clearly named assertion methods, but also by making sure the failure message provides as much information as possible. Consider this example:

"1234567890".Should().Be("0987654321");

This will be reported as:

clip_image001[6]

The fact that both strings are displayed on a separate line is on purpose and happens if any of them is longer than 8 characters. However, if that's not enough, all assertion methods take an optional formatted reason with placeholders, similarly to String.Format, that you can use to enrich the failure message. For instance, the assertion

new[] { 1, 2, 3 }.Should().Contain(item => item > 3, "at least {0} item should be larger than 3", 1);

will fail with:

clip_image002[6]

Examples

To verify 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);

To verify that a 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);
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>."

To verify 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("change the unit of an existing ingredient", ComparisonMode.Substring)
   .And.Violations.Should().Contain(BusinessRule.CannotChangeIngredientQuanity);

What’s new?

May 20th, 2013
@ 
 
March 3rd, 2013
We've released a small bugfix on Nuget and CodePlex.
 
October 7th, 2012
Version 2.0 is now out of beta.
 
August 25th, 2012
Fluent Assertions 2.0, a major new version with support for .NET 4.5, Windows Phone and Windows Store Apps is inbeta. Read all the details in this blog post.
  
January 13th, 2012
A relatively small release. Read all about it in this blog post.
 
October 31st, 2011
Another release with lots of bug fixes and small improvements and with great contributions by Martin Opdam and Urs Enzler. Download ithere or get it throughNuGet.
 

About versioning

The version numbers of Fluent Assertions releases comply to the Semantic Versioning scheme. In other words, release 1.4.0 only adds backwards-compatible functionality and bug fixes compared to 1.3.0. Release 1.4.1 should only include bug fixes. And if we ever introduce breaking changes, the number increased to 2.0.0.

Who are we?

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

If you have any comments or suggestions, please let us know via twitter, through thediscussions page, or throughStackOverflow.

clip_image002#fluentassertions

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 used in many open-source projects. It runs on .NET 3.5, 4.0 and 4.5 (Desktop and Windows Store), Silverlight 4 and 5 and Windows Phone 7.5. And it supports the unit test frameworks NUnit, XUnit, MBUnit, Gallio and MSpec.

Why?

Nothing is more annoying then a unit test that fails without clearly explaining why. More than often, you need to set a breakpoint and start up the debugger to be able to figure out what went wrong. Jeremy D. Miller once gave the advice to "keep out of the debugger hell" and I can only agree with that.

For instance, only test a single condition per test case. If you don't, and the first condition fails, the test engine will not even try to test the other conditions. But if any of the others fail, you'll be on your own to figure out which one. I often run into this problem when developers try to combine multiple related tests that test a member using different parameters into one test case. If you really need to do that, consider using aparameterized test that is being called by several clearly named test cases.

That’s why we designed Fluent Assertions to help you in this area. Not only by using clearly named assertion methods, but also by making sure the failure message provides as much information as possible. Consider this example:

"1234567890".Should().Be("0987654321");

This will be reported as:

clip_image001[6]

The fact that both strings are displayed on a separate line is on purpose and happens if any of them is longer than 8 characters. However, if that's not enough, all assertion methods take an optional formatted reason with placeholders, similarly to String.Format, that you can use to enrich the failure message. For instance, the assertion

new[] { 1, 2, 3 }.Should().Contain(item => item > 3, "at least {0} item should be larger than 3", 1);

will fail with:

clip_image002[6]

Examples

To verify 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);

To verify that a 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);
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>."

To verify 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("change the unit of an existing ingredient", ComparisonMode.Substring)
   .And.Violations.Should().Contain(BusinessRule.CannotChangeIngredientQuanity);

What’s new?

May 20th, 2013
@ 
 
March 3rd, 2013
We've released a small bugfix on NuGet and CodePlex.
 
October 7th, 2012
Version 2.0 is now out of beta.
 
August 25th, 2012
Fluent Assertions 2.0, a major new version with support for .NET 4.5, Windows Phone and Windows Store Apps is inbeta. Read all the details in this blog post.
  
January 13th, 2012
A relatively small release. Read all about it in this blog post.
 
October 31st, 2011
Another release with lots of bug fixes and small improvements and with great contributions by Martin Opdam and Urs Enzler. Download ithere or get it throughNuGet.
 

About versioning

The version numbers of Fluent Assertions releases comply to the Semantic Versioning scheme. In other words, release 1.4.0 only adds backwards-compatible functionality and bug fixes compared to 1.3.0. Release 1.4.1 should only include bug fixes. And if we ever introduce breaking changes, the number increased to 2.0.0.

Who are we?

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

If you have any comments or suggestions, please let us know via twitter, through thediscussions page, or throughStackOverflow.

clip_image002#fluentassertions

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 used in many open-source projects. It runs on .NET 3.5, 4.0 and 4.5 (Desktop and Windows Store), Silverlight 4 and 5 and Windows Phone 7.5. And it supports the unit test frameworks NUnit, XUnit, MBUnit, Gallio and MSpec.

Why?

Nothing is more annoying then a unit test that fails without clearly explaining why. More than often, you need to set a breakpoint and start up the debugger to be able to figure out what went wrong. Jeremy D. Miller once gave the advice to "keep out of the debugger hell" and I can only agree with that.

For instance, only test a single condition per test case. If you don't, and the first condition fails, the test engine will not even try to test the other conditions. But if any of the others fail, you'll be on your own to figure out which one. I often run into this problem when developers try to combine multiple related tests that test a member using different parameters into one test case. If you really need to do that, consider using aparameterized test that is being called by several clearly named test cases.

That’s why we designed Fluent Assertions to help you in this area. Not only by using clearly named assertion methods, but also by making sure the failure message provides as much information as possible. Consider this example:

"1234567890".Should().Be("0987654321");

This will be reported as:

clip_image001[6]

The fact that both strings are displayed on a separate line is on purpose and happens if any of them is longer than 8 characters. However, if that's not enough, all assertion methods take an optional formatted reason with placeholders, similarly to String.Format, that you can use to enrich the failure message. For instance, the assertion

new[] { 1, 2, 3 }.Should().Contain(item => item > 3, "at least {0} item should be larger than 3", 1);

will fail with:

clip_image002[6]

Examples

To verify 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);

To verify that a 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);
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>."

To verify 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("change the unit of an existing ingredient", ComparisonMode.Substring)
   .And.Violations.Should().Contain(BusinessRule.CannotChangeIngredientQuanity);

What’s new?

May 20th, 2013
Through a contribution on GitHub, Ufuk Hacıoğulları has added support for MonoTouch.  
 
March 3rd, 2013
We've released a small bugfix on NuGet and CodePlex.
 
October 7th, 2012
Version 2.0 is now out of beta.
 
August 25th, 2012
Fluent Assertions 2.0, a major new version with support for .NET 4.5, Windows Phone and Windows Store Apps is inbeta. Read all the details in this blog post.
  
January 13th, 2012
A relatively small release. Read all about it in this blog post.
 
October 31st, 2011
Another release with lots of bug fixes and small improvements and with great contributions by Martin Opdam and Urs Enzler. Download ithere or get it throughNuGet.
 

About versioning

The version numbers of Fluent Assertions releases comply to the Semantic Versioning scheme. In other words, release 1.4.0 only adds backwards-compatible functionality and bug fixes compared to 1.3.0. Release 1.4.1 should only include bug fixes. And if we ever introduce breaking changes, the number increased to 2.0.0.

Who are we?

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

If you have any comments or suggestions, please let us know via twitter, through thediscussions page, or throughStackOverflow.

clip_image002#fluentassertions

Created Unassigned: CollectionAssertions.Equal does not handle null properly [12490]

$
0
0
I have the following situation:

string[] expected = null;
string[] result = null;

result.Should().Equal(expected) // Throws Exception

"Expected collection to be equal, but found <null>."

Since the result is equal to the expected, this should not throw an exception.

Commented Issue: Inconsistent ShouldBeEquivalentTo() behaviour for collections of complex types [12484]

$
0
0
I'm having trouble comparing lists of objects that come back in an indeterminate order. I thought `ShouldBeEquivalentTo()` would take care of this for me, but it doesn't seem to :(
Check out the comments in following sample class for a more thorough description.
```
using System.Collections.Generic;
using FluentAssertions;
using NUnit.Framework;

namespace CrazyMo.Tests
{
[TestFixture]
public class ShouldBeEquivalentToTests
{
public class SomeClass
{
public int SomeInt { get; set; }
}
[Test]
public void DoSomethingAwesome_Scenario_ExpectedResult()
{
SomeClass some1 = new SomeClass { SomeInt = 1 };
SomeClass someOther1 = new SomeClass { SomeInt = 1 };
some1.ShouldBeEquivalentTo(someOther1); // This works

IEnumerable<int> someInts = new List<int> {1, 2};
IEnumerable<int> someOtherInts = new List<int> {2, 1};
someInts.Should().BeEquivalentTo(someOtherInts); // This works
someInts.Should().BeEquivalentTo(2, 1); // This works

IEnumerable<SomeClass> actual = new List<SomeClass>
{
new SomeClass{SomeInt = 1},
new SomeClass{SomeInt = 2}
};

// This does work
actual.ShouldBeEquivalentTo(new List<SomeClass>{
new SomeClass { SomeInt = 1 },
new SomeClass { SomeInt = 2 }
});


// The following is in reverse order, just like someOtherInts above.
// This doesn't work, but should?
actual.ShouldBeEquivalentTo(new List<SomeClass>
{
new SomeClass{SomeInt = 2},
new SomeClass{SomeInt = 1}
});
// This is similar to BeEquivalentTo(2, 1) above, but doesn't work.
// It's even in the correct order.
actual.Should().BeEquivalentTo(
new SomeClass { SomeInt = 1 },
new SomeClass { SomeInt = 2 }
);

}
}
}
```
Comments: You could also look for the standard "IComparable" or "IComparable<T>" interface implementations and, if so, you could then use those to determine sorting order. Also, you can use the above or IEquatable<T> to determine things that are equal.

Commented Issue: Inconsistent ShouldBeEquivalentTo() behaviour for collections of complex types [12484]

$
0
0
I'm having trouble comparing lists of objects that come back in an indeterminate order. I thought `ShouldBeEquivalentTo()` would take care of this for me, but it doesn't seem to :(
Check out the comments in following sample class for a more thorough description.
```
using System.Collections.Generic;
using FluentAssertions;
using NUnit.Framework;

namespace CrazyMo.Tests
{
[TestFixture]
public class ShouldBeEquivalentToTests
{
public class SomeClass
{
public int SomeInt { get; set; }
}
[Test]
public void DoSomethingAwesome_Scenario_ExpectedResult()
{
SomeClass some1 = new SomeClass { SomeInt = 1 };
SomeClass someOther1 = new SomeClass { SomeInt = 1 };
some1.ShouldBeEquivalentTo(someOther1); // This works

IEnumerable<int> someInts = new List<int> {1, 2};
IEnumerable<int> someOtherInts = new List<int> {2, 1};
someInts.Should().BeEquivalentTo(someOtherInts); // This works
someInts.Should().BeEquivalentTo(2, 1); // This works

IEnumerable<SomeClass> actual = new List<SomeClass>
{
new SomeClass{SomeInt = 1},
new SomeClass{SomeInt = 2}
};

// This does work
actual.ShouldBeEquivalentTo(new List<SomeClass>{
new SomeClass { SomeInt = 1 },
new SomeClass { SomeInt = 2 }
});


// The following is in reverse order, just like someOtherInts above.
// This doesn't work, but should?
actual.ShouldBeEquivalentTo(new List<SomeClass>
{
new SomeClass{SomeInt = 2},
new SomeClass{SomeInt = 1}
});
// This is similar to BeEquivalentTo(2, 1) above, but doesn't work.
// It's even in the correct order.
actual.Should().BeEquivalentTo(
new SomeClass { SomeInt = 1 },
new SomeClass { SomeInt = 2 }
);

}
}
}
```
Comments: Additionally, you could allow the "Equal" method on a collection to have a 2nd parameter for a compare expression/function. That would be useful as well.

Commented Issue: Inconsistent ShouldBeEquivalentTo() behaviour for collections of complex types [12484]

$
0
0
I'm having trouble comparing lists of objects that come back in an indeterminate order. I thought `ShouldBeEquivalentTo()` would take care of this for me, but it doesn't seem to :(
Check out the comments in following sample class for a more thorough description.
```
using System.Collections.Generic;
using FluentAssertions;
using NUnit.Framework;

namespace CrazyMo.Tests
{
[TestFixture]
public class ShouldBeEquivalentToTests
{
public class SomeClass
{
public int SomeInt { get; set; }
}
[Test]
public void DoSomethingAwesome_Scenario_ExpectedResult()
{
SomeClass some1 = new SomeClass { SomeInt = 1 };
SomeClass someOther1 = new SomeClass { SomeInt = 1 };
some1.ShouldBeEquivalentTo(someOther1); // This works

IEnumerable<int> someInts = new List<int> {1, 2};
IEnumerable<int> someOtherInts = new List<int> {2, 1};
someInts.Should().BeEquivalentTo(someOtherInts); // This works
someInts.Should().BeEquivalentTo(2, 1); // This works

IEnumerable<SomeClass> actual = new List<SomeClass>
{
new SomeClass{SomeInt = 1},
new SomeClass{SomeInt = 2}
};

// This does work
actual.ShouldBeEquivalentTo(new List<SomeClass>{
new SomeClass { SomeInt = 1 },
new SomeClass { SomeInt = 2 }
});


// The following is in reverse order, just like someOtherInts above.
// This doesn't work, but should?
actual.ShouldBeEquivalentTo(new List<SomeClass>
{
new SomeClass{SomeInt = 2},
new SomeClass{SomeInt = 1}
});
// This is similar to BeEquivalentTo(2, 1) above, but doesn't work.
// It's even in the correct order.
actual.Should().BeEquivalentTo(
new SomeClass { SomeInt = 1 },
new SomeClass { SomeInt = 2 }
);

}
}
}
```
Comments: Using IComparable, IComparable<T> and IEquatable<T> is not safe. You would be relying on the implementation for determining the equality of two classes. In most cases, only one or two properties are used to determine if two objects are functionally equivalent. The Equal() overload that takes a predicate already exists in 2.0.

Commented Issue: Inconsistent ShouldBeEquivalentTo() behaviour for collections of complex types [12484]

$
0
0
I'm having trouble comparing lists of objects that come back in an indeterminate order. I thought `ShouldBeEquivalentTo()` would take care of this for me, but it doesn't seem to :(
Check out the comments in following sample class for a more thorough description.
```
using System.Collections.Generic;
using FluentAssertions;
using NUnit.Framework;

namespace CrazyMo.Tests
{
[TestFixture]
public class ShouldBeEquivalentToTests
{
public class SomeClass
{
public int SomeInt { get; set; }
}
[Test]
public void DoSomethingAwesome_Scenario_ExpectedResult()
{
SomeClass some1 = new SomeClass { SomeInt = 1 };
SomeClass someOther1 = new SomeClass { SomeInt = 1 };
some1.ShouldBeEquivalentTo(someOther1); // This works

IEnumerable<int> someInts = new List<int> {1, 2};
IEnumerable<int> someOtherInts = new List<int> {2, 1};
someInts.Should().BeEquivalentTo(someOtherInts); // This works
someInts.Should().BeEquivalentTo(2, 1); // This works

IEnumerable<SomeClass> actual = new List<SomeClass>
{
new SomeClass{SomeInt = 1},
new SomeClass{SomeInt = 2}
};

// This does work
actual.ShouldBeEquivalentTo(new List<SomeClass>{
new SomeClass { SomeInt = 1 },
new SomeClass { SomeInt = 2 }
});


// The following is in reverse order, just like someOtherInts above.
// This doesn't work, but should?
actual.ShouldBeEquivalentTo(new List<SomeClass>
{
new SomeClass{SomeInt = 2},
new SomeClass{SomeInt = 1}
});
// This is similar to BeEquivalentTo(2, 1) above, but doesn't work.
// It's even in the correct order.
actual.Should().BeEquivalentTo(
new SomeClass { SomeInt = 1 },
new SomeClass { SomeInt = 2 }
);

}
}
}
```
Comments: BTW, ignoring the order is already part of the Release-2.1 branch.

Commented Unassigned: CollectionAssertions.Equal does not handle null properly [12490]

$
0
0
I have the following situation:

string[] expected = null;
string[] result = null;

result.Should().Equal(expected) // Throws Exception

"Expected collection to be equal, but found <null>."

Since the result is equal to the expected, this should not throw an exception.
Comments: We'll include your Pull Request. We never ran into this ourselves because our collections are never allowed to be _null_ (because of our coding guidelines).

New Post: Why did you add the And property?

$
0
0
I feel like it's making things far more complicated and less fluent, I don't even consider that to be readable, so my question is why the verbosity? do you have plans to change it?

In fact, to be honest, I think you should remove chaining completely but if you already added it you should go with a less verbose syntax.

New Post: Why did you add the And property?

$
0
0
Yeah, it's one of those features that I don't really like anymore. In fact, I haven't even used it myself. At that time it sounded like a good idea. But when I recently offered to remove it completely, some users complained about that.

Reviewed: Release 2.0.1 (May 28, 2013)

$
0
0
Rated 5 Stars (out of 5) - Stupendous project, it's a required dependency for all my test projects. Should be rolled into .Net like JSON.Net

Created Unassigned: BeEmpty() on a byte array [12491]

$
0
0
imho empty on a byte array means that all bytes is zero, not that the actual length is zero.

The method isn't very useful otherwise as it's quite easy to write Buffer.Count.Should.Be(0);

Commented Unassigned: BeEmpty() on a byte array [12491]

$
0
0
imho empty on a byte array means that all bytes is zero, not that the actual length is zero.

The method isn't very useful otherwise as it's quite easy to write Buffer.Count.Should.Be(0);
Comments: The problem with that is that it would be a breaking change and inconsistent with invoking that method on other collections. Besides, when the count is not what you would expect, you wouldn't get an equally clean answer.

Created Unassigned: Equal and collections of generics = bad message description [12492]

$
0
0
If a Equal test fail on a collection containing generic types (Class<T>) the test failed message returns a generic error message, telling just the index of the collection were the test failed, instead with a normal object graph the message contains the full object text rapresentation that is really useful.

Class samples:

public class BaseStuff
{
public int StuffId { get; set; }
public string Description { get; set; }
}

public class Stuff<TChild> : BaseStuff
{
public List<TChild> Childs { get; set; }
}

Testing with this code:

stuff.Should().NotBeNull()
.And.HaveCount(2)
.And.Equal(expectedStuff, (t1, t2) => t1.StuffId == t2.StuffId && t1.Description == t2.Description);

Case 1 (good message):

var stuff = new List<BaseStuff>();
var expectedStuff = new List<BaseStuff>();

Returned Message if fails:

Expected collection to be equal to {

UnitTestProject1.BaseStuff
{
Description = "Stuff_1"
StuffId = 1
},

UnitTestProject1.BaseStuff
{
Description = "WRONG_DESCRIPTION"
StuffId = 2
}}, but {

UnitTestProject1.BaseStuff
{
Description = "Stuff_1"
StuffId = 1
},

UnitTestProject1.BaseStuff
{
Description = "Stuff_2"
StuffId = 2
}} differs at index 1.

Case 2 (bad message):

var stuff = new List<Stuff<int>>();
var expectedStuff = new List<Stuff<int>>();

Returned Message if fails:

Result Message: Expected collection to be equal to {UnitTestProject1.Stuff`1[System.Int32], UnitTestProject1.Stuff`1[System.Int32]}, but {UnitTestProject1.Stuff`1[System.Int32], UnitTestProject1.Stuff`1[System.Int32]} differs at index 1.


Is there possible to have the same fail message also for generics?

I've attached also the complete test class to test the behavior.

Commented Unassigned: Equal and collections of generics = bad message description [12492]

$
0
0
If a Equal test fail on a collection containing generic types (Class<T>) the test failed message returns a generic error message, telling just the index of the collection were the test failed, instead with a normal object graph the message contains the full object text rapresentation that is really useful.

Class samples:

public class BaseStuff
{
public int StuffId { get; set; }
public string Description { get; set; }
}

public class Stuff<TChild> : BaseStuff
{
public List<TChild> Childs { get; set; }
}

Testing with this code:

stuff.Should().NotBeNull()
.And.HaveCount(2)
.And.Equal(expectedStuff, (t1, t2) => t1.StuffId == t2.StuffId && t1.Description == t2.Description);

Case 1 (good message):

var stuff = new List<BaseStuff>();
var expectedStuff = new List<BaseStuff>();

Returned Message if fails:

Expected collection to be equal to {

UnitTestProject1.BaseStuff
{
Description = "Stuff_1"
StuffId = 1
},

UnitTestProject1.BaseStuff
{
Description = "WRONG_DESCRIPTION"
StuffId = 2
}}, but {

UnitTestProject1.BaseStuff
{
Description = "Stuff_1"
StuffId = 1
},

UnitTestProject1.BaseStuff
{
Description = "Stuff_2"
StuffId = 2
}} differs at index 1.

Case 2 (bad message):

var stuff = new List<Stuff<int>>();
var expectedStuff = new List<Stuff<int>>();

Returned Message if fails:

Result Message: Expected collection to be equal to {UnitTestProject1.Stuff`1[System.Int32], UnitTestProject1.Stuff`1[System.Int32]}, but {UnitTestProject1.Stuff`1[System.Int32], UnitTestProject1.Stuff`1[System.Int32]} differs at index 1.


Is there possible to have the same fail message also for generics?

I've attached also the complete test class to test the behavior.
Comments: Thanks for reporting that issue. I'll look into it.

New Post: OnlyContainItemsOfType method does not exist

$
0
0
The latest version of FluentAssertions (v2.0.1) does not contain a method OnlyContainItemsOfType<T> specified in the documentation.

Is this method planned for the future version or was it already deprecated?

New Post: OnlyContainItemsOfType method does not exist

$
0
0
It's still there, but it was renamed to ContainItemsAssignableTo<T>()....

Regards,

Dennis

Created Unassigned: Print x.0 when x is is a double/float representing a whole number [12493]

$
0
0
I certainly will understand if this does not get picked up since there are a lot of other similar situations that would not be as easy to fix, but it would be a nice-to-have so I thought I would throw it out.

```
var a = new {A = (object) 5};
var b = new {A = (object) 5.0};

a.Should().Be(b);
```

Fails with
> Expected object to be { A = 5 }, but found { A = 5 }.

It would be nice if it failed with
> Expected object to be { A = 5.0 }, but found { A = 5 }.

because then one would not need to go into the debugger to figure out what is different.

Of course this is a very simple example, would be more useful for with things with larger printouts such as more complex objects, or CollectionAssertions.BeEquivalentTo on collections of complex objects.

Viewing all 1402 articles
Browse latest View live


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