Comments on: A new approach to unit tests

By: Stefano MAESTRI

Stefano MAESTRI — Sat, 10 Jan 2009 22:17:03 +0000

What do you mean exactly with “can I copy”?
Where do you want to copy it?

By: purse

purse — Sat, 03 Jan 2009 07:23:23 +0000

hi,
thanks,The article was very well written, very helpful to me

By: TimurAlhimenkov

TimurAlhimenkov — Thu, 01 Jan 2009 21:30:50 +0000

I really liked this post. Can I copy?
Thank you in advance.

Sincerely, Timur.

By: links for 2008-10-30 | iLenceel

links for 2008-10-30 | iLenceel — Thu, 30 Oct 2008 19:07:49 +0000

[...] A new approach to unit tests | Legolas in Minas Tirith BDD [...]

By: Alistair

Alistair — Mon, 27 Oct 2008 09:09:48 +0000

sorry, just realised the xml might not show up in my comment!

By: Alistair

Alistair — Mon, 27 Oct 2008 09:06:47 +0000

Interesting idea. Why annotate every method though? It clutters the code and makes it difficult to change a test hierarchy (you have to change all the class references in code which has nothing to do with the test hierarchy and then recompile that code). Why annotate classes at all? Why not just annotate the interface? The test will know exactly what methods should be tested. It will know the signature of each method so can test each method, without having to annotate every method in the implementing class. So you would do:

@TestedBy(testClass = …
public interface APIInterface {

but that’s too much hard coding for my liking. If you’re going to create a new testing framework, why not consider IOC? Allow the framework to inject the test hierarchy based on an abstraction?

package org.funnyfarm;

@TestedBy(testHierarchy = …
public interface APIInterface {

but you could refine it further by using the interface name as a lookup into a set of hierarchies registered with the framework. i.e. something along the lines of:

@TestedBy
public interface APIInterface {

that way you have one hook in the interface. No hooks in implementation code – APIInterfaceImpl implements APIInterface should be enough for the framework to test APIInterfaceImpl. Who cares what else APIInterfaceImpl does. It might implement another interface but the framework would know that from the signature and test accordingly.

By: A new approach to unit tests « Stefon’s Blog

A new approach to unit tests « Stefon’s Blog — Sun, 26 Oct 2008 10:36:40 +0000

[...] More on this topic can be read in A new approach to unit tests. [...]

By: Stefano MAESTRI

Stefano MAESTRI — Fri, 24 Oct 2008 09:38:54 +0000

@Paul
A lot of good points here. May I ask you to join our discussion group (link in my last post) to help us in our discussions.
Just very brief answer:
1) yep it will be possible to do that. I have already thought about.
2) As said in the article TestedBy will also provide annotations for testclass’ factories. And finally APITest it’s a JUnit class, but @Before can’t accept parameter. As said in another comment @BeforeTestedBy is a very bad name, maybe @InjectTestClassInstance (or somthing like it) would be much better

By: Paul

Paul — Fri, 24 Oct 2008 08:56:38 +0000

I like the idea that one can specify near the code the tests that are expected to be run, and with ide/tool support that could be very powerful.

However two things occur to me after reading your post…

1) with the annotations, i know i would get pretty hacked off writing the testing class name over and over and over again….i dont know if its possible but if so wouldnt it be better to put a testedBy annotation on the class as well and list the test class there? then you wouldnt need to repeat it all the time but if you wanted too could override it in a specific method annotation.

This would of course restrict/ecourage you to put all the tests in one class, but most of us do that anyway dont we? and if you really wanted to you could still use the full anotation on each method….

2) With the interface tests and the running a test against each implementation, how do you envisage getting around the various constructors required for the different implementations?

Currently I specify an abstract class for each Interface, The test methods in it test the interfaces contract, then for each implementation i provide a test class that extends the abstract class… I assume this pattern is used by many of us.

The TestedBy annotations could still be applied to that and would even allow you to ensure that the test classes for an implementation actually extend the abstract test class.

Im still skeptical about the BeforeTestedBy anotation …after all its in the test class ( if i havent missunderstood ) In which case the annotation is then missleading …. Id also unclear if the APITest Class is a JUnit test? If not why not? and if it isnt why not use the Before annotation?

By: Stefano MAESTRI

Stefano MAESTRI — Thu, 23 Oct 2008 07:59:41 +0000

@VonC
yep and it’s exactly what @TestedByList does: array of annotations inside another annotation.