Aristotelian unities for drama unit testing

I was discussing today a recent SE-Radio episode on "The History of JUnit and the Future of Testing with Kent Beck". In this podcast he (among other stuff) mentioned something to the effect that each test case (unit test) should tell a story complete with all the parts of a good story: intro, plot and finale.

My friend could not resist and soon provided me with a following excerpt from the definition of three classical unities of drama:
Aristotelian unities or three unities are rules for drama:
  1. The unity of action: a play should have one main action that it follows, with no or few subplots.
  2. The unity of place: a play should cover a single physical space and should not attempt to compress geography, nor should the stage represent more than one place.
  3. The unity of time: the action in a play should take place over no more than 24 hours.

So, there it is. Your guidelines for writing good unit tests. :)

Comments

Post a Comment

Popular posts from this blog

Musings about build systems

I was just hacking the other day our somewhat horrible hairball of an ant build to try to mold it to my understanding of how a build should work when I had a sort of an epiphany about why on earth I dislike Ant so much. Apart from the syntax (and I think it is universally agreed by now, that XML is a horrible, horrible language for scripting like tasks), what hit me is that while ant is okay for simple one-shot single project builds, it really falls on it's knees as soon as you start building complex modularized systems where you need some sort of dependency management. Now, before I go on, I must mention that I have heard of alternatives like make, Maven , Buckminster , b3 and the ilk, but I really don't know much about any of those (well, by the time I started to write this piece, I had taken a peek at Buckminster). I am not really what you would call a "build person" - I'm using Ant, because it's what comes with most of the projects I've been invol...
Read more

Comparing Jenkins vs TeamCity - Part 1

As some of my closest friends already know, I decided to bite the bullet and switched jobs recently. As the new company I now work for is really small compared to the one I left, it also means that as a developer I am also involved in more than just programming. One of the decisions I had to make and implement was selecting and setting up a CI server for continuous building and deployment of our next product. Having had extensive exposure to CruiseControl, I immediately discarded it as I've developed a particular dislike for this product. The next alternative I had had any exposure to was Hudson ( now renamed to Jenkins ) and JetBrains's TeamCity , which I had heard a lot of nice things about. Adding to the mix that first project to hit our CI server would be .NET project, I needed a solution that would run on Windows and build .NET projects using MSBuild. I settled on Jenkins and TeamCity as the two major contenders. I would like to point out that this post is ful...
Read more

Comparing Jenkins vs TeamCity - Part 2

Image
This is a second installment in a series of posts that tries to compare two continuous integration and build automation server products. In my previous post I briefly introduced the contenders open source developed Jenkins and a commercial offering from JetBrains called TeamCity and compared their respective installation experience. This time I'll try to cover the post-installation configuration steps I need to make before I can start putting some builds into them. Configuration No server software is usually useful out of the box in and by itself. You almost always need to tweak and configure it before you can really reap the benefits. Continuous integration is just another type of server and it needs to be configured before it becomes really useful. TeamCity After you've installed your copy of TeamCity and opened up it's web interface for the first time, it greets you with a nice little license agreement, you need to agree to in order to be able to continue. ...
Read more