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

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 object and a dot, and your IDE will show you all the assertions 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 assertion 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 assertion/reflection library (http://fest.easytesting.org/) which had been recently forked (by one of its most active contributor) to create the more prolific AssertJ library.

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 assertion libraries are two orthogonal topics and concerns.

With NFluent assertion libraries:

With NFluent, you can write simple assertions like this:

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

	var integers = new int[] { 1, 2, 3 };
    Check.That(integers).ContainsOnly(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" };
    Check.That(camus).IsNotEqualTo(sartre).And.IsInstanceOf<Person>();

	var heroes = "Batman and Robin";
    Check.That(heroes).StartsWith("Bat").And.Contains("Robin");

	string motivationalSaying = "Failure is mother of success.";
    Check.That(motivationalSaying).IsNotInstanceOf<int>();

with NFluent, you can also write assertions 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.Properties("Name")).ContainsExactly("Thomas", "Achille", "Anton", "Arjun");
    Check.That(persons.Properties("Age")).ContainsExactly(38, 10, 7, 7);
    Check.That(persons.Properties("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.That(() => { throw new InvalidOperationException(); }).Throws<InvalidOperationException>();

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

• Because you think like us that writing a lambda expression within an assertion statement is not really a fluent experience (neither on a reading perspective).
• 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 assertion 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 assertions (i.e. NFluent's Check.That).
• And 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).

Can't be more easy: NFluent is available on nuget.org

NFluent use cases are available here.

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

Nfluent backlog is now available as github issues

• 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 on the library, but you need a feature not yet implemented, don't hesitate to request it on the NFluent-Discuss google group. In any cases: you are welcome!

• To the other contributors: Marc-Antoine LATOUR, Rui CARVALHO & Cyrille DUPUYDAUBY.

• To Rui CARVALHO, for the nice NFluent logo he has designed.

• To the mates that gave me ideas and feedbacks to make this lib as fluent as possible: Joel COSTIGLIOLA (former active contributor of Java FEST Assert, which now works on his AssertJ fork), Rui CARVALHO, Cyrille DUPUYDAUBY, Benoit LABAERE, ...

• To Omer RAVIV, which supports the NFluent project by offering us some free licenses for the nice BugAid Visual Studio extensions.

• To Jetbrains, which still creates some of the coolest tools for developers (whatever the language), and which supports our NFluent project by providing us some space within their TeamCity code better instance (note: you can enter as guest).

  

  YouTrack by JetBrains: keyboard-centric bug tracker - TeamCity by JetBrains: continuous integration server

thomas@pierrain.net / April 2013