Category Archives: Testing

The path to Alfresco enlightenment

I started working with Alfresco back in 2005 and the code base was a lot smaller back then! More recently I’ve seen people try to dive into WebScript development without a concrete understanding of the foundational elements of the API. When I was set the task of organising an internal ‘hackathon’ as part of a ‘company day’ I decided that the goal should be to create a hands-on code-based tutorial.
Continue reading

Relevancy Driven Development with Solr

The relevancy of search engine results is very subjective so therefore testing the relevancy of queries is also subjective.
One technique that exists in the information retrieval field is the use of judgement lists; an alternative approach discussed here is to follow the Behaviour Driven Development methodology employing user story acceptance criteria – I’ve been calling this Relevancy Driven Development or RDD for short.

I’d like to thank Eric Pugh for a great discussion on search engine testing and for giving me a guest slot in his ‘Better Search Engine Testing‘ talk* at Lucene EuroCon Barcelona 2011 last week to mention RDD. The first iteration of Solr-RDD combines my passion for automated testing with my passion for Groovy by leveraging EasyB (a Groovy BDD testing framework).

Continue reading

Code coverage and meaningful unit tests

It always worries me if I spot something like the following in a unit test during a code review:

testSomething {
  helper.foo()
}

Whilst this exercises a path through the code base (which helps to appease Cobertura), ensures that no exceptions are thrown and there are no ‘typo’ errors in the Groovy code (e.g. wrong property) it isn’t a valid test. A valid ‘black-box’ test should apply known input and compare the output to the expected output.

Ok, so this problem doesn’t just apply to unit tests – it can happen with automated integration tests or functional tests too. However for the unit test you should use mock collaborators to allow the test to just exercise the ‘unit under test’.

The real underlying problem is that the developer isn’t follow the Test Driven Development process. They’ve taken on board that the “code must have 80% automated unit test coverage” but are going about it in the wrong way. So it’s time for some re-education on why the tests must check the output and why writing the test first helps them think about how the class needs to work. Alternatively go for a behaviour driven approach and make the requirements executable!

Now I wonder if I can quickly write a CodeNarc ruleset to flag any test methods that don’t contain assertions…