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. 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/).
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).
With NFluent assertion libraries:
All you've got to remember is: Check.That
, cause every assertion is then provided via a super-duper-auto-completion-dot-experience ;-)
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");
- 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 don't think that writing a lambda expression within an assertion statement is really a fluent experience (neither on a reading perspective).
- Because like us, you dislike the
<subjectUnderTest>.Should().
syntax (which we find not semantically as strong as theAssert
or theCheck.That
ones). - And because you like killing features added as bonus, such as the Properties() extension method for IEnumerable for instance (as showed within the usage sample above).
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 contributors: Marc-Antoine LATOUR, Rui CARVALHO.
-
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, Rui CARVALHO, Cyrille DUPUYDAUBY, Benoit LABAERE, ...
[email protected] / March 2013