Created
June 29, 2010 14:01
-
-
Save AlexZeitler/457248 to your computer and use it in GitHub Desktop.
my thoughts on grouping #bdd items using #vscommands - any other ideas?
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Bar.cs | |
| +-BarSpecs.cs | |
| Foo.cs | |
| +- FooSpecs.cs | |
| vs. | |
| Bar.cs | |
| BarSpecs.cs (with common Bar related IBehaviorConfigs) | |
| +- when_bar_has_this.cs | |
| +- when_bar_has_that.cs | |
| Foo.cs | |
| FooSpecs.cs (with common Foo related IBehaviorConfigs) | |
| +- when_foo_does_this.cs | |
| +- when_foo_does_that.cs |
+1
I tried it with when_foo.cs a couple of years ago and failed due to unwieldy long file names (plus, duplication of context names in the file name and the context class). The *Specs.cs convention also makes it easier to set all files containing specs to have zero bytes later in the release build.
Thanks guys, sounds reasonable to me.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At the moment I would favour:
Bar.cs
+- BarSpecs.cs
and optionally
Bar.cs
+- BarThisSpecs.cs
+- BarThatSpecs.cs
+- BarOtherSpecs.cs
Because the grouping is only visible in VS, there should be some coherence in the file system.