# NUnit

NUnit is a unit-testing framework for all .NET languages.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Behavior Driven Development in C#

DevFeed: [Behavior Driven Development in C#](<https://devfeed.tech/articles/behavior-driven-development-in-c-33385.md>)

Original publisher: [Read original article](<https://timkellogg.me/blog/2011/12/28/behavior-driven-development-in-c>)

Published: 2011-12-28T00:00:00Z

Content type: opinion

Language: en

Sources: [Tim Kellogg](<https://devfeed.tech/sources/tim-kellogg.md>)

Topics: [Behavior-driven development](<https://devfeed.tech/topics/bdd.md>), [C#](<https://devfeed.tech/topics/csharp.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [NUnit](<https://devfeed.tech/topics/nunit.md>), [RSpec](<https://devfeed.tech/topics/rspec.md>), [Test-driven development](<https://devfeed.tech/topics/tdd.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>)

Tags: [bdd](<https://devfeed.tech/tags/bdd.md>), [c-sharp](<https://devfeed.tech/tags/c-sharp.md>), [nunit](<https://devfeed.tech/tags/nunit.md>), [rspec](<https://devfeed.tech/tags/rspec.md>), [ruby](<https://devfeed.tech/tags/ruby.md>), [testing](<https://devfeed.tech/tags/testing.md>), [unit-test](<https://devfeed.tech/tags/unit-test.md>), [unit-testing](<https://devfeed.tech/tags/unit-testing.md>)

### AI overview

The author explains why behavior-driven development became more manageable than conventional unit-test naming for complex code. They compare Ruby RSpec and .NET BDD approaches, and describe a simple BDD layer over NUnit to preserve its tooling and lower the barrier to contribution.

### Source excerpt

I've been a fan of Test Driven Development since I worked in an XP shop. But every time the work starts getting bigger and more complex I always struggle to not get lost in the magnitudes of tests. I remember many early-on conversations with my elders about unit test naming conventions. The [method]_[input]_[output] convention starts to break down badly when your inputs become things like mocks, or if there ends up being more than 1 or 2 inputs; same with outputs.When a coworker introduced me to BDD earlier this year, it really clicked and flowed naturally. The idea of writing tests so they read like sentences out of a book or spec seems like the answer to all my questions. The ruby rspec is beautiful:The organization of the tests forces you to focus on the expectations of your test and highlight descriptive assertions. This is especially useful for complicated setups with lots of mocks, etc. I put as much of my setup code in one of those before :each blocks, so that way the assertions are limited to simple inputs and one or two observations about the outputs.There's been a number of people in the .NET community that have attempted BDD but [imo] failed to grasp the simplicity. NBehave is a complete overhaul of unit testing that uses attributes like xUnit. As a result, NBehave doesn't really look at all like rspec - which really isn't a bad thing, necessarily. However, the thing I like about rspec is it's ability to describe things of arbitrary depth, which is handy when testing complex code:This spec is able to describe possible modes that the object under test can be in (complex inputs). This is made possible by rspec's arbitrary nesting depth. This is definitely a language feature that is much harder to implement in C#.My current approach to BDD in C# usually looks likeI think this is the simplest BDD layer I can slap on top of NUnit. And simple is important to me because (a) I do a lot of open source projects and I want to keep the barrier to entry for contributi

## NUnit Extension Methods

DevFeed: [NUnit Extension Methods](<https://devfeed.tech/articles/nunit-extension-methods-33359.md>)

Original publisher: [Read original article](<https://timkellogg.me/blog/2011/02/26/nunit-extension-methods>)

Published: 2011-02-26T00:00:00Z

Content type: tutorial

Language: en

Sources: [Tim Kellogg](<https://devfeed.tech/sources/tim-kellogg.md>)

Topics: [NUnit](<https://devfeed.tech/topics/nunit.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [Unit testing](<https://devfeed.tech/topics/unit-testing.md>), [Code](<https://devfeed.tech/topics/code.md>), [Framework](<https://devfeed.tech/topics/framework.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [framework](<https://devfeed.tech/tags/framework.md>), [nunit](<https://devfeed.tech/tags/nunit.md>), [object](<https://devfeed.tech/tags/object.md>), [static](<https://devfeed.tech/tags/static.md>), [testing](<https://devfeed.tech/tags/testing.md>), [unit-testing](<https://devfeed.tech/tags/unit-testing.md>)

### AI overview

This article presents NUnit extension methods that wrap common assertions such as Assert.AreEqual, Assert.IsNull, and Assert.IsNotNull. The methods provide a more readable style, including calls such as actual.ShouldBe(expected) and actual.ShouldBeNull().

### Source excerpt

I've always used NUnit for testing code so it's naturally the framework I'm most familiar with (I haven't used anything else). I learned unit testing using the classic Assert.AreEqual(expected, actual) methods. Although, I was finding my tests slightly confusing to read - I sometimes can't remember which comes first, expected or actual.More recently I've been getting into v2.5 including the new asserts - Assert.That(actual, Is.EqualTo(expected)). I think this makes a lot of sense and I often find myself using Assert.That most of the time just because it makes sense.Recently, a coworker created a few extension methods that I'm finding quite handy:public static void ShouldBe(this object @this, object expected) { Assert.AreEqual((dynamic)expected, (dynamic)@this);}public static void ShouldNotBe(this object @this, object expected) { Assert.AreNotEqual((dynamic)expected, (dynamic)@this);}public static void ShouldBeNull(this object @this) { Assert.IsNull(@this);}public static void ShouldNotBeNull(this object @this) { Assert.IsNotNull(@this);}I've completely fallen in love with how this reads: actual.ShouldBe(expected). It also makes me giggle to do actual.ShouldBeNull() (Don't you love extension methods?). This makes unit testing so easy...