BDD – Files/Folders/Namespaces (BDD)

One thing that can be troublesome when moving to a BDD style approach is how to organize your files and folders, so far I’ve tried two approaches:

  1. One class in each file – So if you have When_associating_an_order_with_a_customer and When_associating_an_order_with_a_preferred_customer then they’d be in seperate files even though they are very closely related. If they share a base class, or a class they both compose, then that would be in yet another class (presumably).
  2. Multiple classes per file – As an example you might group the Order addition contexts into a file called OrderPlacementSpecifications, the file could also contain the shared base class (if you went down that road).

To me the second approach has a couple of advantages:

  1. Gives the reader extra information – By grouping the two order placement classes we tell the reader that they are quite closely related.
  2. Simplifies folder structure – If we go for the other approach, one class in each file, then we’re probably going to have to have more folders. The addition of the extra files and folders definitely makes the solution file harder to structure.

To give you an idea here’s a screen shot of a part of the folder structure for a sample app we’re doing:


In addition to files/folders I’ve tried a few approaches to structuring namespaces but the approach I’m trying now groups related artifacts. For example:

  1. Specifications.Users.Domain
  2. Specifications.Users.Domain.Contacts
  3. Specifications.Users.Services
  4. Specifications.Users.Domain.Repositories
  5. Specifications.Users.UI.Controllers

The “Specifications” bit adds very little but I think grouping all specifications related to users is useful, not least as R# makes it easy to run all the specifications in a namespace. This can be useful if you have a big solution and only want to run the specifications for the area your working on. Its also worth saying that its “Users” to avoid clashing with the “User” class.

Folder wise however we’re using a standard approach where your Repositories are in a completely seperate folder from your controllers, even though they might both relate to a particular entity. To me the lack of relationship between our folders and namespaces isn’t a problem though, with R# its easy to find a file/type and in addition the folder/namespace tell you two different things about your codebase (one by “layer”, one by “feature”).

So I’m interested in peoples views? I’m guessing you’ll all dislike it though because from what I’ve seen no matter what you do people will be unhappy with your file/folder/namespace scheme. Pluse we’ll probably turn against this approach next week….

This entry was posted in BDD, TDD. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

7 Responses to BDD – Files/Folders/Namespaces (BDD)

  1. Ray Houston says:

    I’ve tried all sorts of ways and I’m not trilled about any of them. We’re currently doing #1 but we expand out the namespaces more. We have folder names like UserContacts.when_doing_some_action and then we’ll have classes with names like when_doing_some_action_in_some_context. Then main reason for doing this was to not have files 1000 lines of spec code in there for all the different contexts. Like you, I’ll probably change my mind next week.

  2. Michael Sevestre says:

    I’ve also tried different approaches. The one we are using now is sligthly different and at first sight a bit weird, but it made a lot of sens after a short while: We are having each specs file(with one or more classes) live beside the code it is testing (i.e. in the same project!). We then use an Nant skript to deploy the application, that among other things, removes the “*specs” file from the assembly. Works like a charm. A bonus with this approach, is that you have also access to internal methods of your sut.

  3. Colin Jack says:

    Nice suggestion, will definitely give that a shot.

    The whole tests with code under test things always been a little radical for me but I can definitely see the value. I’m always behind the times on these sorts of things :)

  4. I’m curious about this as well, as the specs I’ve written quickly get numerous and hard to navigate.

    This is still a problem with my “legacy” tests, even more so actually.

    I like the nice view that I get when running my specs in R# or NUnit’s runner, but when browsing around code it’s not nearly as easy.

    What if I’m currently writing code for a component, and I need to add a new tests. R#’s CTRL+N brings up the type dialog and I type “when_” and I get a barrage of unrelated specs.

  5. colinjack says:

    Yeah the whole search for when_ is a big annoying, I tend to find the SUT then do a find usages and then see all the specs for it. If our test classes are attributed with something like [Conerning(typeof(Account))] then we can search on that (and hope that at some point R# or whatever will take advantage of this sort of metadata.

    Not great solutions though.

  6. Michael Sevestre says:


    You could browse by file instead with R# using CRTL+SHIFT+N which allows you for example to find the OrderSpecs file, which contains all tests for an Order.

  7. jcteague says:

    I tend to use CustomerSpecs.cs as the file name and have multiple classes in each file. I then use what Ben suggested, R# Find by file name. This was been the easiest so far. If I have a ton of test for Customer then I think about breaking the file up into two or three files and keep the classes orgainzed logically within those.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>