--- title: "The evolution of Unit Testing Syntax and Semantics" url: "https://osherove.com/blog/2008/1/17/the-evolution-of-unit-testing-syntax-and-semantics.md" canonical: "https://osherove.com/blog/2008/1/17/the-evolution-of-unit-testing-syntax-and-semantics.html" published: "2008-01-17T04:21:59" updated: "2008-01-17T04:21:59" tags: ["Agile", "Agile Related", "Art Of Unit Testing", "General Software Devel...", "Unit Testing", "altnetconf"] author: "Roy Osherove" description: "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…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # The evolution of Unit Testing Syntax and Semantics By Roy Osherove January 17, 2008 In [Agile](https://osherove.com/blog/category/agile), [Agile Related](https://osherove.com/blog/category/agile-related), [Art Of Unit Testing](https://osherove.com/blog/category/art-of-unit-testing), [General Software Devel...](https://osherove.com/blog/category/general-software-devel), [Unit Testing](https://osherove.com/blog/category/unit-testing), [altnetconf](https://osherove.com/blog/category/altnetconf) **Historical article** · Originally published January 17, 2008; technical details may be outdated. 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](http://weblogs.asp.net/rosherove/archive/2005/04/03/TestNamingStandards.aspx) for unit tests seem to be something people are actively looking for. - **Simplicity** is back: [XUnit](http://www.codeplex.com/xunit) tries to go back to basics: No setup\\teardown, different attribute names.   - **Fluent**: My implementation of [NRehersal](http://weblogs.asp.net/rosherove/archive/2008/01/09/scala-nrehersal-and-fluent-test-interfaces.aspx) uses delegates and a more fluent interface for tests **Mocking** - **Mocks Vs. Stubs**: The Difference is [explored](http://martinfowler.com/articles/mocksArentStubs.html) ([here](http://martinfowler.com/articles/mocksArentStubs.html) 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](http://weblogs.asp.net/rosherove/archive/2005/06/18/413577.aspx)) - **Auto Mocking** Containers (introduced by [Elutian](http://blog.eleutian.com/CommentView,guid,762249da-e25a-4503-8f20-c6d59b1a69bc.aspx)) will use RhinoMocks and Ioc Containers under the test covers (back to base classes) - **Mocking the Un-Mockable**: [TypeMock](http://typemock.com/) (and [JMockIt](https://jmockit.dev.java.net/) 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](http://spec-unit.rubyforge.org/), [RBehave](http://dannorth.net/2007/06/introducing-rbehave) and [RSpec](http://rspec.rubyforge.org/) 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](http://exceptionz.wordpress.com/2006/09/13/rspec-specifications-in-c/). - [NUnit.Behave](http://www.lostechies.com/blogs/joe_ocampo/archive/2007/06/28/introducing-nunit-behave-or-insert-what-ever-other-catchy-name.aspx), [NBehave](http://nbehave.org/), [NSpec](http://nspec.tigris.org/) , [NSpecify](http://nspecify.sourceforge.net/) try to use DSLs and fluent interfaces to express BDD specs. - Jeremy [shows off his version](http://codebetter.com/blogs/jeremy.miller/archive/2008/01/17/spiking-a-new-syntax-for-integration-tests-whaddaya-think.aspx) of a more fluent and natural spec syntax by taking the auto mocking container idea, using [structuremap](http://structuremap.sourceforge.net/Default.htm) 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! ## More in Agile [All posts in Agile](https://osherove.com/blog/category/agile) - Jan 18, 2008 ### [Trying out Team City - Looks Promising!](https://osherove.com/blog/2008/1/18/trying-out-team-city-looks-promising.html) - Jan 17, 2008 ### [Is Typemock too powerful? Will it kill design for testability?](https://osherove.com/blog/2008/1/17/is-typemock-too-powerful-will-it-kill-design-for-testability.html) - Jan 15, 2008 ### [Typemock Snippets and future](https://osherove.com/blog/2008/1/15/typemock-snippets-and-future.html) - Jan 12, 2008 ### [Unit Testing at TechEd Israel 08 - Which talk would you choose?](https://osherove.com/blog/2008/1/12/unit-testing-at-teched-israel-08-which-talk-would-you-choose.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/