ISerializable - Roy Osherove's Blog

The evolution of Unit Testing Syntax and Semantics

The semantics of how you write a unit test, the basic syntax, or Domain Specific language of how we write them, has been relatively stale for quite some years now.  But under the covers, the syntax revolution seems to be brewing, as people try to come up with newer, hopefully better and more readable syntaxes for tests and specifications that become more and more complex as the current Agile community struggles to accept best practices in this arena.

I'm guilty of that too, but a recent post by Jeremy Miller prompted me to try and list all the different syntax variations I've come across in the .net and some in java world (not necessarily in chronological order). Most ofthese didn't necessarily catch on as de facto standards, but are real world attempts to make a better world or explore new horizons.

POUT (Plain Old Unit Test) Syntax

• JUnit initial syntax
• Attributes: NUnit with attribute syntax, removing inheritance and test naming requirements
• Extensibility: MbUnit is extensible testing framework with lots of powerful attributes.
• Naming conventions for unit tests seem to be something people are actively looking for.
• Simplicity is back: XUnit tries to go back to basics: No setup\teardown, different attribute names.  
• Fluent: My implementation of NRehersal uses delegates and a more fluent interface for tests

Mocking

• Mocks Vs. Stubs: The Difference is explored (here too) and makes its way into some of the mock frameworks (NMock, JMock, Rhino.Mocks)
• Explicit (reflection based) mocking statements such as (New DynamicMock(typeof(Interface), mock.Expect(...))
• Record-replay syntax from Rhino.Mocks, EasyMock, TypeMock and others
• fluent mocking APIs into our tests (NMock2)
• Auto Mocking Containers (introduced by Elutian) will use RhinoMocks and Ioc Containers under the test covers (back to base classes)
• Mocking the Un-Mockable: TypeMock (and JMockIt on the java side) introduce the possibility of mocking production code that is currently untestable without needing to refactor it.

BDD, Specifications and other Domain Specific Languages

• Ruby SpecUnit, RBehave and RSpec make a dent in the .NET community and stuff start showing up in our world:
• Extension Methods: Scott bellware comes up with the idea of using C# 3.0 extension methods for an easier expectation syntax.
• NUnit.Behave, NBehave, NSpec , NSpecify try to use DSLs and fluent interfaces to express BDD specs.
• Jeremy shows off his version of a more fluent and natural spec syntax by taking the auto mocking container idea, using structuremap under the covers and creating something that tries to be much more declarative and understandable at the same time. He uses delegates a lot as well.

I'm probably forgetting a few here, so let me know in the comments.

So, we see a nice evolution from beginner style to bdd and spec style. lots of work on the syntax is done, but there is currently lots of chaos. Think Blue-Day Vs. HD-DVD, only with about 5 main competitors. The nice thing about this: The community will decide what worls, so it would be interesting to see where we are one year or a two years from now in relation to this list!