Comments on: BDD – Files/Folders/Namespaces (BDD)

By: jcteague

jcteague — Mon, 03 Nov 2008 02:53:18 +0000

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.

By: Michael Sevestre

Michael Sevestre — Wed, 29 Oct 2008 19:33:55 +0000

@Ben

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.

By: colinjack

colinjack — Wed, 29 Oct 2008 17:54:00 +0000

@Ben
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.

By: Ben Scheirman

Ben Scheirman — Wed, 29 Oct 2008 16:36:11 +0000

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.

By: Colin Jack

Colin Jack — Wed, 29 Oct 2008 15:07:21 +0000

@Ray
Nice suggestion, will definitely give that a shot.

@Michael
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

By: Michael Sevestre

Michael Sevestre — Wed, 29 Oct 2008 11:56:40 +0000

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.

By: Ray Houston

Ray Houston — Wed, 29 Oct 2008 00:07:46 +0000

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.