Rated 5 Stars (out of 5) - I've been using Fluent Assertions for a couple of years now and pulling it down from Nuget has become as automatic for me as creating the test project itself.
↧
Reviewed: Release 2.0.1 (Jun 25, 2013)
↧
Commented Unassigned: Print x.0 when x is is a double/float representing a whole number [12493]
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.
Comments: Is there a way to determine whether a float is a whole number?
```
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.
Comments: Is there a way to determine whether a float is a whole number?
↧
↧
Commented Issue: add new string assertion .Should().BeInFormat(format, args) [12467]
This is similar to wildcards, but I think it will be useful too. If maintainers says ok for that I will be happy to contribute an implementation.
Comments: Could you please explain what the method should do exactly?
Comments: Could you please explain what the method should do exactly?
↧
Created Unassigned: XElement .Should().Be() gives false positives. [12494]
The current implementation of the Be assertion for XElement is implemented in such a way as to cause apparent false positive tests. It only checks the element names, but other Be() assertions in FluentAssertions tend to work closer to equals.
The following test should not pass, but does because the Be comparison does a name check.
[Test]
public void XElement_Be_Assertion_Should_Be_Deeper()
{
var expected =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild")));
var actual =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild2")));
actual.Should().Be(expected);
}
Either Be (And NotBe) should be hidden/removed for XElement or it should do something a much better check:
Worse case the check would be to call ToString() on both XElements and do a string comparison. The reason I don't just resort to this is that the formatted message for a string comparison is not as helpful as a message catered specifically for XElement might be.
The following test should not pass, but does because the Be comparison does a name check.
[Test]
public void XElement_Be_Assertion_Should_Be_Deeper()
{
var expected =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild")));
var actual =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild2")));
actual.Should().Be(expected);
}
Either Be (And NotBe) should be hidden/removed for XElement or it should do something a much better check:
Worse case the check would be to call ToString() on both XElements and do a string comparison. The reason I don't just resort to this is that the formatted message for a string comparison is not as helpful as a message catered specifically for XElement might be.
↧
Commented Unassigned: XElement .Should().Be() gives false positives. [12494]
The current implementation of the Be assertion for XElement is implemented in such a way as to cause apparent false positive tests. It only checks the element names, but other Be() assertions in FluentAssertions tend to work closer to equals.
The following test should not pass, but does because the Be comparison does a name check.
[Test]
public void XElement_Be_Assertion_Should_Be_Deeper()
{
var expected =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild")));
var actual =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild2")));
actual.Should().Be(expected);
}
Either Be (And NotBe) should be hidden/removed for XElement or it should do something a much better check:
Worse case the check would be to call ToString() on both XElements and do a string comparison. The reason I don't just resort to this is that the formatted message for a string comparison is not as helpful as a message catered specifically for XElement might be.
Comments: So what you're suggesting is that we do some kind of deep XML graph comparison?
The following test should not pass, but does because the Be comparison does a name check.
[Test]
public void XElement_Be_Assertion_Should_Be_Deeper()
{
var expected =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild")));
var actual =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild2")));
actual.Should().Be(expected);
}
Either Be (And NotBe) should be hidden/removed for XElement or it should do something a much better check:
Worse case the check would be to call ToString() on both XElements and do a string comparison. The reason I don't just resort to this is that the formatted message for a string comparison is not as helpful as a message catered specifically for XElement might be.
Comments: So what you're suggesting is that we do some kind of deep XML graph comparison?
↧
↧
Commented Unassigned: XElement .Should().Be() gives false positives. [12494]
The current implementation of the Be assertion for XElement is implemented in such a way as to cause apparent false positive tests. It only checks the element names, but other Be() assertions in FluentAssertions tend to work closer to equals.
The following test should not pass, but does because the Be comparison does a name check.
[Test]
public void XElement_Be_Assertion_Should_Be_Deeper()
{
var expected =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild")));
var actual =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild2")));
actual.Should().Be(expected);
}
Either Be (And NotBe) should be hidden/removed for XElement or it should do something a much better check:
Worse case the check would be to call ToString() on both XElements and do a string comparison. The reason I don't just resort to this is that the formatted message for a string comparison is not as helpful as a message catered specifically for XElement might be.
Comments: At best. At worse I'd say remove the methods because I think they don't operate as expected.
The following test should not pass, but does because the Be comparison does a name check.
[Test]
public void XElement_Be_Assertion_Should_Be_Deeper()
{
var expected =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild")));
var actual =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild2")));
actual.Should().Be(expected);
}
Either Be (And NotBe) should be hidden/removed for XElement or it should do something a much better check:
Worse case the check would be to call ToString() on both XElements and do a string comparison. The reason I don't just resort to this is that the formatted message for a string comparison is not as helpful as a message catered specifically for XElement might be.
Comments: At best. At worse I'd say remove the methods because I think they don't operate as expected.
↧
Commented Unassigned: XElement .Should().Be() gives false positives. [12494]
The current implementation of the Be assertion for XElement is implemented in such a way as to cause apparent false positive tests. It only checks the element names, but other Be() assertions in FluentAssertions tend to work closer to equals.
The following test should not pass, but does because the Be comparison does a name check.
[Test]
public void XElement_Be_Assertion_Should_Be_Deeper()
{
var expected =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild")));
var actual =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild2")));
actual.Should().Be(expected);
}
Either Be (And NotBe) should be hidden/removed for XElement or it should do something a much better check:
Worse case the check would be to call ToString() on both XElements and do a string comparison. The reason I don't just resort to this is that the formatted message for a string comparison is not as helpful as a message catered specifically for XElement might be.
Comments: I'm considering to implement the following http://stackoverflow.com/questions/7318157/best-way-to-compare-xelement-objects/13048775#13048775
The following test should not pass, but does because the Be comparison does a name check.
[Test]
public void XElement_Be_Assertion_Should_Be_Deeper()
{
var expected =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild")));
var actual =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild2")));
actual.Should().Be(expected);
}
Either Be (And NotBe) should be hidden/removed for XElement or it should do something a much better check:
Worse case the check would be to call ToString() on both XElements and do a string comparison. The reason I don't just resort to this is that the formatted message for a string comparison is not as helpful as a message catered specifically for XElement might be.
Comments: I'm considering to implement the following http://stackoverflow.com/questions/7318157/best-way-to-compare-xelement-objects/13048775#13048775
↧
Commented Unassigned: XElement .Should().Be() gives false positives. [12494]
The current implementation of the Be assertion for XElement is implemented in such a way as to cause apparent false positive tests. It only checks the element names, but other Be() assertions in FluentAssertions tend to work closer to equals.
The following test should not pass, but does because the Be comparison does a name check.
[Test]
public void XElement_Be_Assertion_Should_Be_Deeper()
{
var expected =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild")));
var actual =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild2")));
actual.Should().Be(expected);
}
Either Be (And NotBe) should be hidden/removed for XElement or it should do something a much better check:
Worse case the check would be to call ToString() on both XElements and do a string comparison. The reason I don't just resort to this is that the formatted message for a string comparison is not as helpful as a message catered specifically for XElement might be.
Comments: Looks like a good approach, I must admit I didn't even know DeepEquals existed, but Eric White's approach seems good. Thanks for looking into this.
The following test should not pass, but does because the Be comparison does a name check.
[Test]
public void XElement_Be_Assertion_Should_Be_Deeper()
{
var expected =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild")));
var actual =
new XElement("parent"
, new XElement("child"
, new XElement("grandChild2")));
actual.Should().Be(expected);
}
Either Be (And NotBe) should be hidden/removed for XElement or it should do something a much better check:
Worse case the check would be to call ToString() on both XElements and do a string comparison. The reason I don't just resort to this is that the formatted message for a string comparison is not as helpful as a message catered specifically for XElement might be.
Comments: Looks like a good approach, I must admit I didn't even know DeepEquals existed, but Eric White's approach seems good. Thanks for looking into this.
↧
New Post: Support for C# Dynamics
For me both - static equivalent and declaring test item as an object work fine.
↧
↧
Created Unassigned: Collection should contain other collection behaving unexpectedly [12495]
I want to assert that a collection of simple objects includes a smaller collection of the same object type. For some reason actualCollection.Should().Contain(expectedCollection) is failing with a message that shows all of the expected objects are in the actual collection but it's claiming that they aren't.
Here's the assertion failure output I'm getting:
```
Expected collection {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends"
percentage = 0
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "only me"
percentage = 0
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}} to contain {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}}, but could not find {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}}
```
Here's the assertion failure output I'm getting:
```
Expected collection {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends"
percentage = 0
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "only me"
percentage = 0
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}} to contain {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}}, but could not find {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}}
```
↧
Commented Unassigned: Collection should contain other collection behaving unexpectedly [12495]
I want to assert that a collection of simple objects includes a smaller collection of the same object type. For some reason actualCollection.Should().Contain(expectedCollection) is failing with a message that shows all of the expected objects are in the actual collection but it's claiming that they aren't.
Here's the assertion failure output I'm getting:
```
Expected collection {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends"
percentage = 0
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "only me"
percentage = 0
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}} to contain {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}}, but could not find {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}}
```
Comments: I ended up taking a different approach to work around this issue. I filter out the objects I know shouldn't show up in my expected collection and then use the Equal assertion with a predicate function. ``` actualCollection.Where(p => p.percentage > 0).Should().Equal(expectedCollection, (a,e) => a.category == e.category && a.percentage == e.percentage); ```
Here's the assertion failure output I'm getting:
```
Expected collection {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends"
percentage = 0
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "only me"
percentage = 0
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}} to contain {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}}, but could not find {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}}
```
Comments: I ended up taking a different approach to work around this issue. I filter out the objects I know shouldn't show up in my expected collection and then use the Equal assertion with a predicate function. ``` actualCollection.Where(p => p.percentage > 0).Should().Equal(expectedCollection, (a,e) => a.category == e.category && a.percentage == e.percentage); ```
↧
Commented Unassigned: Collection should contain other collection behaving unexpectedly [12495]
I want to assert that a collection of simple objects includes a smaller collection of the same object type. For some reason actualCollection.Should().Contain(expectedCollection) is failing with a message that shows all of the expected objects are in the actual collection but it's claiming that they aren't.
Here's the assertion failure output I'm getting:
```
Expected collection {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends"
percentage = 0
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "only me"
percentage = 0
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}} to contain {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}}, but could not find {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}}
```
Comments: I suspect that your class is not implementing Equals(). In that case FA would use reference equality.
Here's the assertion failure output I'm getting:
```
Expected collection {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends"
percentage = 0
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "only me"
percentage = 0
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}} to contain {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}}, but could not find {
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "custom"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "friends of friends"
percentage = 0.333333333333333
},
ActivityServiceTest.DataTypes.SocialItemSummary
{
category = "public"
percentage = 0.333333333333333
}}
```
Comments: I suspect that your class is not implementing Equals(). In that case FA would use reference equality.
↧
Edited Feature: Show details about an AggregateException in ShouldNotThrow [12482]
When an AggregateException is thrown it would be nice if ShouldNotThrow shows the details about the inner exception. Now you only see that an AggregateException is thrown, but is is more interesting to know what the inner exceptions are.
↧
↧
Edited Issue: Inconsistent ShouldBeEquivalentTo() behaviour for collections of complex types [12484]
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 }
);
}
}
}
```
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 }
);
}
}
}
```
↧
Commented Issue: Inconsistent ShouldBeEquivalentTo() behaviour for collections of complex types [12484]
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: It's part of the 2.1
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: It's part of the 2.1
↧
Commented Issue: Extend ShouldThrow*() to Func [12148]
Extend the ShouldThrow*() methods for Func<Task> too so you can work with async methods:
Func<Task> foo = async () => { await DoSthAsync(); }
foo.ShouldThrow<ArgumentNullException>();
Comments: Doesn't work in FA 2.0.1: // Act Action action = async () => await controller.GetUserInformation(userInformation); // Assert action.ShouldThrow<HttpResponseException>(); Error: Result Message: Expected System.Web.Http.HttpResponseException, but no exception was thrown. During debugging another exception is thrown. So why messages states about "no exception" ?
Func<Task> foo = async () => { await DoSthAsync(); }
foo.ShouldThrow<ArgumentNullException>();
Comments: Doesn't work in FA 2.0.1: // Act Action action = async () => await controller.GetUserInformation(userInformation); // Assert action.ShouldThrow<HttpResponseException>(); Error: Result Message: Expected System.Web.Http.HttpResponseException, but no exception was thrown. During debugging another exception is thrown. So why messages states about "no exception" ?
↧
Commented Issue: Extend ShouldThrow*() to Func [12148]
Extend the ShouldThrow*() methods for Func<Task> too so you can work with async methods:
Func<Task> foo = async () => { await DoSthAsync(); }
foo.ShouldThrow<ArgumentNullException>();
Comments: Please neglect. Should use instead: Func<Task<HttpResponseMessage>> func = ... func.ShouldThrow<HttpResponseException>();
Func<Task> foo = async () => { await DoSthAsync(); }
foo.ShouldThrow<ArgumentNullException>();
Comments: Please neglect. Should use instead: Func<Task<HttpResponseMessage>> func = ... func.ShouldThrow<HttpResponseException>();
↧
↧
Created Unassigned: Assembly not correctly loaded in Mono 3.2.0 [12496]
It seems that a project that references FluentAssertions.dll is not correctly loaded in Xamarin Studio 4.0 (on Mac OS X).
If I remove the reference and I'm also unable to install it with NuGet Package Mgr (the new one for X.Studio).
B.Regards,
Giacomo S.S.
If I remove the reference and I'm also unable to install it with NuGet Package Mgr (the new one for X.Studio).
B.Regards,
Giacomo S.S.
↧
Commented Unassigned: Assembly not correctly loaded in Mono 3.2.0 [12496]
It seems that a project that references FluentAssertions.dll is not correctly loaded in Xamarin Studio 4.0 (on Mac OS X).
If I remove the reference and I'm also unable to install it with NuGet Package Mgr (the new one for X.Studio).
B.Regards,
Giacomo S.S.
Comments: I want to add that with a fresh new project, the problem doesn't present itself. I'm able to add the assembly. My suggestion is to remove the reference with the original NuGet that added it and then re-add it with X.Studio.
If I remove the reference and I'm also unable to install it with NuGet Package Mgr (the new one for X.Studio).
B.Regards,
Giacomo S.S.
Comments: I want to add that with a fresh new project, the problem doesn't present itself. I'm able to add the assembly. My suggestion is to remove the reference with the original NuGet that added it and then re-add it with X.Studio.
↧
Commented Unassigned: Assembly not correctly loaded in Mono 3.2.0 [12496]
It seems that a project that references FluentAssertions.dll is not correctly loaded in Xamarin Studio 4.0 (on Mac OS X).
If I remove the reference and I'm also unable to install it with NuGet Package Mgr (the new one for X.Studio).
B.Regards,
Giacomo S.S.
Comments: I don't understand what you mean? What reference to 'the original Nuget'?
If I remove the reference and I'm also unable to install it with NuGet Package Mgr (the new one for X.Studio).
B.Regards,
Giacomo S.S.
Comments: I don't understand what you mean? What reference to 'the original Nuget'?
↧