Friday, January 13, 2012

Fluent Assertions 1.7.0 has been released

It has barely been more than two months ago, but the number of downloads through CodePlex and Nuget combined has exceeded 2000. Me and co-author Martin Opdam thought that to be a nice reason for releasing a new version of Fluent Assertions. This isn't a big release, but since we are following semantic versioning and we added new functionality as well as some bug fixes, an increment in the minor number is in order. Since we prefer NuGet ourselves, get the latest version through its NuGet landing page. If you prefer the old-fashioned way, get it through CodePlex. Here are the release notes.

What's New

  • Added methods for asserting that a collection of types matching a predicate have specific methods that are virtual or marked with a specific attribute.
typeof(MyController).Methods()
.ThatReturn<ActionResult>()
.ThatAreDecoratedWith<HttpPostAttribute>()
.Should()
.BeDecoratedWith<ValidateAntiForgeryTokenAttribute>(
"because all Actions with HttpPost require ValidateAntiForgeryToken");


  • Added methods for asserting XElements and Xattributes

xDocument.Should().HaveRoot("configuration");
xDocument.Should().HaveElement("settings");

xElement.Should().HaveAttribute("age", "36");
xElement.Should().HaveElement("address");

xAttribute.Should().HaveValue("Amsterdam");


  • Added support for recursively comparing the properties of nested (collection of objects ). By default it will compare all properties of the expected object graph, unless SharedProperties is used.
  • Added a fallback mechanism so that if FA cannot find any of the supported frameworks, it will fall back to using a custom AssertFailedException exception class rather than crashing.
  • Added support for ComparisonMode.StartWith and ComparisonMode.StartWithEquivalent when asserting the message of an exception.
Bug Fixes & Improvements



  • For assertions that verify against a Type, the failure message will use the AssemblyQualifiedName rather than just the name of the type.
  • Fixed a bug so that collection.Should().OnlyContain(lamba) now throws if the collection is empty. See this discussion for more details.
  • Minor fix that ignores trailing blank characters when looking for the 'because' text in the reason of an assertion.
  • Added better and deeper detection of cyclic references when recursively comparing properties or generating a string representation of a complex object graph.
  • For long strings, the error message for string.Should().StartWith() places the actual and expected strings on seperate lines. This makes it easier to find the differences.

By the way, we’ve also spent some time updating the documentation.

6 comments:

Adam Ralph said...

Thanks for the updates. Good to see continued activity on my favourite fluent assertion library.

Jerrie Pelser said...

Hi,

Just started using your library and so far I find it excellent. One thing though: I use it for comparing NHibernate objects and sometimes I have objects with bi-directional references. The assertions fails and states that a cyclic reference was detected. Could it be possible though to configure that instead of throwing an exception on a cyclic reference that it should rather just not follow that reference and still complete the rest of the comparison successfully?

Thanks

Dennis Doomen said...

I'll add a feature request to the Fluent Assertions CodePlex page.

Carl G said...

Hi, I'm using FluentAssertions 1.7.1 with .NET4.0 and NHibernate 3.2. When I call the method .Should() on a model class (e.g. "Product") or an ICollection, I get the following error:

"The call is ambiguous between the following methods or properties: FluentAssertions.AssertionExtensions.Should(System.Xml.Linq.XElement)' and 'FluentAssertions.AssertionExtensions.Should(System.Xml.Linq.XDocument)'

Any idea what I am doing wrong? Thanks for the great idea and software.

Dennis Doomen said...

Did you include the appropriate namespace? Because I'm completely flabbergasted on why the compiler would select an extension method for XML types, rather than an ICollection. Your Product class doesn't happen to inherit from some XML base-class, does it?

Matt said...

From my experiences, you need to add references to System.XML and System.Xml.Linq - and no, my class under test doesn't inherit from anything XML based. A default MSTest project doesn't have these 2 references though.