Comments on Captain Debug's Blog: Declarative Unit Testing: Is JUnit Obsolete?

Disclosure – I wrote Sureassert, thanks to Captain...

2011-08-31T16:31:33.255+01:00

Disclosure – I wrote Sureassert, thanks to Captain Debug for the article!

manuel aldana – thanks very much for your comments. Of course a basic example is given for simplicity and brevity; there is way more powerful stuff you can do with Exemplars, in particular using results from one into the instance or input of others. A nice way to set your object under test is to use the result of an Exemplar defined on a constructor or factory method, or you may want to use a named Spring bean.

Three main points I want to make: firstly Exemplars are for unit tests, not integration or functional tests. These typically run more complex scenarios. Secondly, Exemplars don’t fit every unit test requirement (I make no claim they kill JUnit!). But they do promote the idea of formalizing standard unit tests into a typical template, namely:
a. Create or otherwise retrieve an object (the “object under test”),
b. Execute a method on the object under test with typical inputs, and
c. Assert one or more expected results on the method’s returned value, thrown exception, the object under test’s state, and/or the state of some other affected object.
Typically you might also:
d. Setup stubs or mocks to force external dependencies to behave in a manner determined by the unit test, and
e. Assert the behaviour of the method under test, e.g. what methods have been invoked by the method under test and in what way.

These are the things you define in your Exemplar (or UseCase), which has the potential wipe out a large percentage of your coded tests. The rest can still be managed by the Sureassert engine.

I would say, if you have unit tests that are on average 10 times more logically complex than your production code, you may have a problem with the complexity of your unit test approach (although I can’t purport to know your specific circumstances of course!) If you have a test with a branch, you may well have 2 tests in one test method which would be represented by 2 separate Exemplars.

Thirdly, with an Exemplar, if necessary you’re quite welcome to call out to a method in your test source to make complex assertions on the Exemplar result or the test instance, via a simple invocation expression. The idea is to simplify typical tests such that this isn’t usually necessary however. You may consider Exemplars a good approach to supporting smaller, modular and more focussed and specified units in your production code.

Apologies that the site is lacking a little in documentation thus far. I’m working on a quick guide that will introduce the concepts, features and techniques.

To the contributor who didn’t like annotations in code – might not win you over, but there is the option of annotating your interfaces instead – Exemplars get inherited (potentially from multiple interfaces). Declaring the javadoc contract and Exemplars in your interfaces is a nice approach for contract-driven designs I think.

One last thing, even if you don’t use Exemplars, you might find Sureassert useful for the continuous testing and real-time coverage reporting support for your JUnit tests. Please feel free to give it a try, I’ll try to offer help on the forums!

Thanks for the comments on scaling and mock/stub o...

2011-08-29T21:02:29.844+01:00

Thanks for the comments on scaling and mock/stub objects. Yes, this is a VERY simple example, but the SureAssert technique does provide for Test Doubles, Method Stubs and Source Stubs. For more information on this take a look at: http://www.sureassert.com/uc/features/declarative-stubbing/.

Interesting approach, where the test is used to al...

2011-08-29T19:31:31.221+01:00

Interesting approach, where the test is used to also document tightly to the actual code

But I see problems:
The above prod-code is trivial. It is a static method and from itself well testable. I wonder how this works with with more complicated domain-objects or handler objects (based on interfaces), and with higher cyclomatic complexity (if/else logic). I remember recently I had 200 LOC (compact + non-duplicated) text-cases/test-code which tested 20 LOC prod-code. I really doubt that SureAssert scales...

But still thanks for sharing (I like new approaches to testing).

Python has a similar tool in doctest. I wonder t...

2011-08-29T17:33:32.647+01:00

Python has a similar tool in doctest.

I wonder though how you are going to inject mock dependencies using this style without getting dirty.

Will you implement an interface within the annotations?

Adding test-related annotations to production code...

2011-08-29T16:54:47.218+01:00

Adding test-related annotations to production code doesn't seem like a cool idea. It does look nice in clean for the simple examples though.

Python has similar concept, called doctest, but in...

2011-08-29T16:41:28.114+01:00

Python has similar concept, called doctest, but instead of annotations you have to use method level documentation. The problem with this approach is that this is fairly limited, basically you can test only pure functions, and java is not a functional language, thus interaction testing (mocking) is often needed. And mocking also has a lot of advantages, it can drive the design towards the good direction.

I really don't think that SureAssert is an abu...

2011-08-29T15:19:14.827+01:00

I really don't think that SureAssert is an abuse of annotations. The annotations merely tell SureAssert how to test your code. The SureAssert eclipse plugin generates and runs the tests.

Although I have do not vested interest in the product I do like the idea that tests are not just an afterthought added on after you've written your code - they should be an integral part of development and promoted to the level of compiler errors. I wouldn't go so far as wanting to mix test code (i.e. JUnit code) with the application code, so specifying tests as simple annotations that allow automatic test generation seems a good idea to me.

looks very promising, yes unit testing is a pain, ...

2011-08-29T13:48:57.811+01:00

looks very promising, yes unit testing is a pain, thank for highlighting it.

That is a terrible abuse of annotations. Its bad ...

2011-08-29T13:42:23.408+01:00

That is a terrible abuse of annotations. Its bad enough to mix your configuration with your code. Now we're going to mix in our tests with our source?

For Python there is an Doctests - tests that are e...

2011-08-29T13:11:06.125+01:00

For Python there is an Doctests - tests that are embedded in functions' docstring.
As far as I know, Ruby also has something similar.

Looks really good for single-method unit testing.....

2011-08-29T12:08:07.574+01:00

Looks really good for single-method unit testing... now if only you could get something similar for integration testing.

I'd also be interested in how this style could be ported to other languages... trying to think how I could do something similar for ruby right now :)