# BDD ideas for structuring tests

DevFeed: [BDD ideas for structuring tests](<https://devfeed.tech/articles/bdd-ideas-for-structuring-tests-33387.md>)

Original publisher: [Read original article](<https://timkellogg.me/blog/2012/01/02/bdd-ideas-for-structuring-tests>)

Published: 2012-01-02T00: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>), [unit tests](<https://devfeed.tech/topics/unit-tests.md>), [NUnit](<https://devfeed.tech/topics/nunit.md>), [Visual Studio](<https://devfeed.tech/topics/visual-studio.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>), [testing](<https://devfeed.tech/tags/testing.md>), [tests](<https://devfeed.tech/tags/tests.md>), [unit-tests](<https://devfeed.tech/tags/unit-tests.md>), [visual-studio](<https://devfeed.tech/tags/visual-studio.md>)

## AI overview

The author discusses ways to structure behavior-driven development tests in C#. The article considers nested classes that organize tests by method, notes their compatibility with Visual Studio navigation, and compares that approach with namespace- and method-based setup practices.

## Source excerpt

Lately I've been thinking a lot about the best way to do BDD in C#. So when I saw Phil Haack's post about structuring unit tests, I think I had a joyful thought. Earlier I had been thinking in terms of using my Behavioral NUnit experimental project to hash out Haack's structuring idea with better BDD integration.In short, his idea is to use nested classes. There is the normal one-to-one class-to-test-class mapping, but each method under test gets it's own inner class. To use his example:In this example the Titleify and Knightify methods (imo two terrible uses of the -ify suffix) have corresponding test classes dedicating to testing only one method. Each method in the class (or Fact, in the case of xUnit. I actually haven't used xUnit but it seems to encourage a somewhat BDD readability) test one aspect of the method, much like the it method is used in rspec.I generally like Haack's test structure. For example, he points out how it plays nicely with Visual Studio's natural class/method navigation which makes the tests even more navigable. The only issue I have with it is that I dislike having 1000+ SLOC classes - tests or regular. If I were to adopt this method, I would probably break each of those inner classes into separate files (and use partial classes to break up the top class).My practice for a long time was to have one whole namespace per class under test. Consider my tests for objectflow. I actually picked up this practice from Garfield Moore, objectflow's original developer. Each class (or significant concept) has a namespace (e.g. objectflow.stateful.tests.unit.PossibleTransitions or PossibleTransitionTests). Each class in that namespace is names according to essentially what the Setup does. Some examples: WhenGivenOnlyBranches, WhenGivenOnlyYields, etc.I like the way these tests read. It's very easy to find a particular test or to read up on how a particular method is supposed to operate. But in practice this has led to very deep hierarchies, often with si