19 October 2007

"Testing towards A Specification: A Systematic Approach"

Peter Dimov has published his Master's thesis. To quote him:

It is based on Test Driven Development with Mock Objects, hence the focus is on interaction-based testing. I'm introducing the mocking framework CalitkoMocks, which is specially designed to provide a notation for writing tests that can be mapped one-to-one to sequence diagrams. Sequence diagrams are classically used to specify object-oriented software systems, however, it is obvious that just a bunch of diagrams representing individual cases cannot really be regarded as a specification. To address this point, I'm also presenting a few test refactorings which help to extract test scenarios (i.e. generalized test cases), which are more suitable to use as a specification.

He's implemented a mock framework for C++ that's part of Calitko

I especially liked his closing remark

After I drew the diagram corresponding to my test, I decided to try to write a test corresponding one-to-one to the sequence diagram. The sequence diagram showed the calls to my stub objects but my test didn’t (because the implementation invoked them implicitly). I ended up writing smarter versions of my stubs which eventually evolved into mocks. Though I had already read about mocks at that time, I didn’t quite get it what kind of beasts these were. It was only after I reinvented the mock that I truly understood the concept.

Perhaps this is a step on the way to addressing Jason Gorman's concerns.

1 comment:

Not Invented Here said...

I like his closing statement too. WHen ever I teach TDD, I never teach how to use a framework, instead I teach them to roll their own. Plus I endeavour to get the attendees to continue to roll their own mocks on the actual work projects for the first 3 months. So that they learn and 'reinvent' what mocks are. Those that do this, generally use the mocking frameworks better. They still manage to produce good quality code. Whereas those that jump straight to the frameworks tend to produce tightly coupled code at best.