👁 Image
NFluent 3.1.0

👁 GitHub stars

Stable 👁 NuGet
👁 NuGet

Beta 👁 MyGet
👁 MyGet

Chat 👁 Gitter

Issues 👁 GitHub issues
👁 GitHub closed issues

Build Status 👁 Build status
👁 Codecov
👁 AppVeyor tests
👁 Mutation testing badge

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

Official site: http://www.n-fluent.net/

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 and it most famous fork 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" };
 Check.That(camus).IsNotEqualTo(sartre).And.IsInstanceOf<Person>();

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

 int? one = 1;
 Check.That(one).HasAValue().Which.IsStrictlyPositive().And.IsEqualTo(1);

 const Nationality FrenchNationality = Nationality.French;
 Check.ThatEnum(FrenchNationality).IsNotEqualTo(Nationality.Korean);

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

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(nameof(Person.Name))).ContainsExactly("Thomas", "Achille", "Anton", "Arjun");
 Check.That(persons.Extracting(nameof(Person.Age))).ContainsExactly(38, 10, 7, 7);
 Check.That(persons.Extracting(nameof(Person.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(nameof(Person.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 nuget.org

Use cases

.

Newsgroup

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

BackLog

Nfluent backlog is now available as github issues

New feature to be added?

• If you want to join the project and contribute: , 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

• Rui has published a great article about the NFluent extensibility model. Available here on CodeDistillers

Many thanks

• To the other amazing 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 AppVeyor CI, which now supports NFluent builds.

/ September 2016