Smooth your .NET TDD experience with NFluent! NFluent is an ergonomic assertion library which aims to fluent your .NET TDD experience (based on simple Check.That() assertion statements). NFluent aims your tests to be fluent to write (with a super-duper-happy 'dot' auto-completion experience), fluent to read (i.e. as close as possible to plain En…
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.
.build Rename Core 2.1 test projects Jul 18, 2018
Images Add new logo Jun 26, 2018
Tools Integrate Cyrille DUPUYDAUBY's refactoring (couldn't merge it properl… May 1, 2017
WebSite WebSite: remove reference to plugin Jan 5, 2018
src Update language version for release version as well Aug 16, 2018
tests Implement #262 : add Which support to IsInstanceOf Aug 16, 2018
.gitattributes Declare .psd as binary within the .gitattributes May 10, 2017
.gitignore Remove reporting to appveyor for some tests projects Jun 21, 2018
.mailmap Add mailmap files Mar 13, 2018 Replace the jetbrains teamcity status by the new AppVeyor one Sep 8, 2016
CI.cmd Remove invalid nuget publish key Jun 7, 2017 Update Apr 28, 2018 Update Dec 10, 2017 Update Dec 10, 2017 CI: increase patch version number and change copyright to 2018 Jan 10, 2018 Fix the link to Rui's blog post Jun 13, 2017 Create Apr 28, 2018
LICENSE.txt Adds the Apache 2.0 LICENSE.txt file. Feb 18, 2013 Add file Mar 24, 2016
NFluent.nuspec Fix #258 and #259 Aug 4, 2018
NFluent.sln Rename Core 2.1 test projects Jul 18, 2018
NFluent.sln.DotSettings Refactor: migrated Code checks Mar 14, 2018
NFluent.snk Integrate Cyrille DUPUYDAUBY's refactoring (couldn't merge it properl… May 1, 2017
NFluentBanner.png Sets the proper logo for NFluent (the one designed by @rhwy) Apr 2, 2013 Update Mar 8, 2018 Implement #262 : add Which support to IsInstanceOf Aug 16, 2018
Settings.StyleCop Adds the IsSetBefore check for EventWaitHandler instance (e.g. Manual… May 31, 2014 Continues to rename/migrate from an IFluentAssertion world to a IChec… Jun 20, 2013
Version.cs Bump version to 2.4.0 Jun 28, 2018
appveyor.yml Bump version to 2.4.0 Jun 28, 2018
build.cmd CI: upgraded several dependencies Aug 21, 2017

GitHub stars

NFluent Motto

Stable NuGet NuGet

PreReleases NuGet Pre Release

Beta MyGet MyGet


GitHub issues GitHub closed issues

Build Status

Build status Codecov AppVeyor tests

NFluent is an assertion library which aims to fluent your .NET TDD experience.

Official site:

NFluent will make your tests:

  • fluent to write: with a super-duper-happy auto-completion 'dot' experience. Indeed, just type the Check.That( followed by one of your objects and a dot, and your IDE will show you all the checks available for the type of the given object to verify. No more, no less (i.e. no auto completion flooding).
  • fluent to read: very close to plain English, making it easier for non-technical people to read test code.
  • fluent to troubleshoot: every failing check of the NFluent library throws an Exception with a crystal-clear message status to ease your TDD experience (see examples below). Thus, no need to set a breakpoint and to debug in order to be able to figure out what went wrong.
  • helpful to reverse engineer legacy code: indeed, temporarily write an on-purpose failing assert on a legacy method, so you can understand it and leverage on the "ready-to-be-copied-and-paste-for-arrays-or-collections-initialization-purpose" NFluent assert failure messages.
  • less error-prone: indeed, no more confusion about the order of the "expected" and "actual" values you can find in the classical .NET unit tests frameworks.

NFluent is directly inspired by the awesome Java FEST Fluent check/reflection library ( which had been recently forked (by one of its most active contributor) to create the more prolific AssertJ library.

NFluent & unit test frameworks

NFluent is not coupled to any .NET unit test framework. It is fully designed to work in collaboration with your favorite one.

Your favorite unit test framework (e.g. NUnit, xUnit, ...) will still handle the test identification, execution & Co. All you have to do is to replace your usage of its Assert or Assert.That() statements, by the Check.That() NFluent statement form. That's all!

Indeed, we decided to use the Check.That() syntax to avoid collisions and name ambiguity with the traditional Assert class you can find in most of your .NET unit test frameworks (therefore, no need to declare an alias in your test fixtures).

In fact, test runners and check libraries are two orthogonal topics and concerns.

As simple as possible

With Nfluent check libraries:

All you've got to remember is: Check.That, 'cause every check is then provided via a super-duper-auto-completion-dot-experience ;-)

Usage sample

With NFluent, you can write simple checks like this:

    var integers = new int[] { 1, 2, 3, 4, 5, 666 };
    Check.That(integers).Contains(3, 5, 666);

    integers = new int[] { 1, 2, 3 };
    Check.That(integers).IsOnlyMadeOf(3, 2, 1);

    var guitarHeroes = new[] { "Hendrix", "Paco de Lucia", "Django Reinhardt", "Baden Powell" };
    Check.That(guitarHeroes).ContainsExactly("Hendrix", "Paco de Lucia", "Django Reinhardt", "Baden Powell");

    var camus = new Person() { Name = "Camus" };
    var sartre = new Person() { Name = "Sartre" };

    var heroes = "Batman and Robin";

    int? one = 1;

    const Nationality FrenchNationality = Nationality.French;

    string motivationalSaying = "Failure is the mother of success.";

with NFluent, you can also write checks like this:

	 var persons = new List<Person>
                                     new Person { Name = "Thomas", Age = 38 },
                                     new Person { Name = "Achille", Age = 10, Nationality = Nationality.French },
                                     new Person { Name = "Anton", Age = 7, Nationality = Nationality.French },
                                     new Person { Name = "Arjun", Age = 7, Nationality = Nationality.Indian }

    Check.That(persons.Extracting("Name")).ContainsExactly("Thomas", "Achille", "Anton", "Arjun");
    Check.That(persons.Extracting("Age")).ContainsExactly(38, 10, 7, 7);
    Check.That(persons.Extracting("Nationality")).ContainsExactly(Nationality.Unknown, Nationality.French, Nationality.French, Nationality.Indian);

    // more fluent than the following classical NUnit way, isn't it?
    // CollectionAssert.AreEquivalent(persons.Properties("Age"), new[] { 38, 10, 7, 7 });

    // it's maybe even more fluent than the java versions
	// FEST fluent assert v 2.x:
    // assertThat(extractProperty("name" , String.class).from(inn.getItems())).containsExactly("+5 Dexterity Vest", "Aged Brie", "Elixir of the Mongoose", "Sulfuras, Hand of Ragnaros", "Backstage passes to a TAFKAL80ETC concert", "Conjured Mana Cake");
	// FEST fluent assert v 1.x:
	// assertThat(inn.getItems()).onProperty("name").containsExactly("+5 Dexterity Vest", "Aged Brie", "Elixir of the Mongoose", "Sulfuras, Hand of Ragnaros", "Backstage passes to a TAFKAL80ETC concert", "Conjured Mana Cake");

or like this:

	// Works also with lambda for exception checking
	Check.ThatCode(() => { throw new InvalidOperationException(); }).Throws<InvalidOperationException>();

	// or execution duration checking
	Check.ThatCode(() => Thread.Sleep(30)).LastsLessThan(60, TimeUnit.Milliseconds);

Why NFluent, and not another .NET fluent check framework?

  • Because you think like us that writing a lambda expression within a check statement is not really a fluent experience (for reading as well as writing).
  • Because NFluent is completely driven by the super-duper-happy-path principle to fluent your TDD experience. For instance, we consider the 'dot' autocompletion experience as crucial. Thus, it should not be polluted by things not related to the current unit testing context (which occurs with extension methods on classical .NET types - intellisense flooding).
  • Because you think that those other check libraries have not chosen the proper vocabulary (<subjectUnderTest>.Should().... why don't they choose Must instead?!?). And thus, you'd rather rely on a stronger semantic for your checks (i.e. NFluent's Check.That).
  • Because you like killing features and extra bonus, such as the Properties() extension method for IEnumerable for instance (as showed within the usage sample above).
  • And because it's awesome pal. Try it, you will see!

Samples of crystal-clear error messages




Wanna try NFluent?

Can't be more easy: NFluent is available on


Use cases

NFluent use cases are available here.


For any comment, remark or question about the library, please use the NFluent-Discuss google group.


Nfluent backlog is now available as github issues

New feature to be added?

  • If you want to join the project and contribute: check this out before before, but be our guest.
  • If you don't want to contribute to the library, but you need a feature not yet implemented, don't hesitate to request it on the NFluent-Discuss google group. In any case: you are welcome!

Other resources

Many thanks / September 2016