Comments on: Changing how I structure unit tests

By: Jon Kruger

Jon Kruger — Mon, 30 Jan 2012 00:59:47 +0000

Tim,

The thing is that now that before_each is split up into multiple Given methods, so it’s not as messy. Sometimes those Given methods are still a little messy, and sometimes I still need a “before_each” style setup method that sets up mocks and stubs that apply to all of the tests. But at least it’s readable now.

By: Tim

Tim — Sun, 29 Jan 2012 22:07:01 +0000

Interesting. A question…

Large set-up of dependencies always make my “before_each” (your “establish_context” above) type methods pretty large, so I’m guessing that happens in your Given method. Is that the case in practice? Or do you build the context elsewhere to keep the Given clean?

By: Andrew

Andrew — Sun, 29 Jan 2012 13:04:45 +0000

Thanks for posting this Jon. I have noticed a lot of discussion on StackOverflow about how to structure unit tests in a BDD style, and have seen tools such as NBehave and MSpec promoted. The problem is, it requires a developer to really think about what the test code is doing, not what the semantics of the test actually are.

That being said, I have favored using Gherkin to drive the unit testing layer and have used SpecFlow to implement my Specs. However, I am going to have to try the approach you are sharing here. It is elegantly simplistic, and quickly helps developers to know exactly how a unit of code should behave and potentially allows us to share this more easily with non-technical people.

At the end of the day, I truly think that unit tests, behavior tests, and acceptance tests should be written so anyone (technical or not) could pick up a test and understand what is being tested.

Thanks again!

By: Erik

Erik — Wed, 18 Jan 2012 21:44:17 +0000

I’ve never seen tests structured like that before, and it’s interesting. I’m wondering if you could set up a fluent interface paradigm where all of the helpers return an instance of the class under test. (I haven’t really thought through the details, but the possibility of having Assert(Given().When().Then()) seems interesting)