Unit tests, acceptance tests and documentation – trying to strike the optimal balance

Lately I’ve been coding away on my hobby project Bumblebee. Bumblebee is about integrating your documentation into you test cases and get human-readable documents from it.

My strongest impressions so far are:

Documentation, acceptance testing and the features of the application are in symbiosis. When I add features in Bumblebee, I start out writing the documentation for it, which is a comment in the test case or a test method. This forces me to think of how I present the feature to the user, and the resulting text keeps me on track while developing the feature. It also helps me see duplication in features much earlier than I would otherwise. Then I add an assertion for the resulting document to get a failing test case.Then I add the code to make the test pass. When refactoring the code and tests aggressively, I realize additional things about the application that I wouldn’t have if I only had unit tested it, and I come up with things that make the application better, as when I realize the same things with unit tests I usually only improve the unit, which often proves to be a sub-optimization.

I don’t miss my unit test that much. I rather am pretty happy for not having them around.

So far, this has proven to be a rather successful strategy that feels easy to work with, so I will continue full speed straight ahead to see where the next wall is…


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: