Skip to content

Latest commit

 

History

History
171 lines (117 loc) · 9.95 KB

ReadMe.md

File metadata and controls

171 lines (117 loc) · 9.95 KB
Raw

NFluent Motto Build status

NFluent is an check 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 object 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 (http://fest.easytesting.org/) 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" };
    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.IsPositive().And.IsEqualTo(1);

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

    string motivationalSaying = "Failure is 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("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 an check 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 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

ErrorSample1

ErrorSample2

ErrorSample3

Wanna try NFluent?

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

nuget

Uses cases

NFluent use cases are available here.

Newsgroup

For any comment, remark or question on 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: 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!

Other resources

Many thanks

[email protected] / September 2016