Raible Designs

Many people have remarked on JUnit's apparent inefficiency when it comes to dealing with the setUp() method. What you have to realise is that is was a concious design decision made to call setUp() prior to each test call in order to isolate one test from another. If setUp() was called only once, there is a potential for one test to impact on another by changing common data. Likewise by using static data, you are opening yourself to the possibility that testOne could manipultae your static data, and testTwo would then be operating in a different environment. In this specific instance you should be OK, however its probably not a pattern you want to use too often as it may well bite you on the ass further down the line.

Posted by Sam Newman on April 08, 2004 at 08:27 AM MDT #

!You can simly use junit.extensions.TestSetup class for that purposes For example i am using in-container Jetty server to run WebUnit tests and Jetty started only once, not for every test. It works like a dream. So there is my JettyTestSetup [{Java2HtmlPlugin public class JettyTestSetup extends TestSetup { protected static Server server; public JettyTestSetup(Test test) { super(test); } protected void setUp() throws Exception { server = new Server(); server.addListener(new InetAddrPort(9000)); WebApplicationContext webapp = server.addWebApplication("/", "context"); webapp.setDefaultsDescriptor("config/webdefault.xml"); server.start(); } protected void tearDown() throws Exception { System.out.println("Stopping server..."); server.stop(); } } }]

Posted by wassup on April 08, 2004 at 09:36 AM MDT #

Hmm...sent a trackback from my blog post but it didn't appear here...

Posted by Sam Newman on April 08, 2004 at 10:28 AM MDT #

I agree the line between unit and integration/functional tests is not always a clear one. You could argue that Matt could Mock out the application context, however if you assume that all external tools are 'safe' then using Spring to produce the context is an acceptable time saving (from the point of view of writing the test). LEts put it another way - what if my test calls a utility class? On the one hand I'm effectively testing the utility class itself, but I tend to be pragmatic about such things. If the other classes I'm using are part of the same project I'll mock them out, if its an external API I'm more inclined to allow their use.

In the case of your Hibernate DAO's for example, in testing the DAO's themselves I would contact the database via Hibernate. If I was using the DAO in a different test I would mock them out rather than contacting the DB - if you assume that the DAO has loaded from the DB you put yourself in the situation of being unable to have several tests run and fail (which is possible if all tests are isolated) - if your DAO fails to load, tests which rely on them will also fail.

Posted by Sam Newman on April 08, 2004 at 12:55 PM MDT #

Well, I think that the idea of IOC is that you don't have to mock out the context: if you need unit testing a bean that depends on other beans, it's those other beans that you should mock, and pass them to the bean under test. The problem that arises with context creation, is: "given that I want to test a number of objects with their dependencies, how do I create a testing environment where that context is correctly initialized (once) when I do execute my tests?". The problem is not only about dependencies: in Spring, for example, a good number of functionalities are provided declaratively or via AOP features. You want to unit test the business logic in beans, but I personally want to test those beans in their context, where they have their behaviour completed by the AOP infrastructure. This is not only true for integration tests, but also for performance tests: in the integration test suite I began working with, there are classes that help running a number of tests in parallel threads and measure the overall throughput: this only makes sense when the logic is completed by spring features. Another issue: if you use the HibernateInterceptor in order to have automatic Hibernate session closing, your bean logic is not complete, without that interceptor: so your test should take it into account: you could impose the interceptor by writing code that manually weaves it's behaviour into the classes you are testing, but since this is already written in the applicationContext.xml and it's "normal" for your classes being executed in the context, then the natural idea is for them to be tested in that context. I agree that pure business logic should be tested in isolation, but code that needs to be performance-tested against database access must be tested in that way (if you are interested, for example, in testing the services layer - i.e. business logic + data access - in a web-layer independent way, of course, if not you could probably directly test it with web-testing tools such as astra load tester or similar stuff).

Posted by Davide Baroncelli on April 08, 2004 at 01:50 PM MDT #

Time for a junit replacement? After all it's such a simple framework that it should not be difficult not only to rewrite, but also for ide providers to implement... Although: is the "instantiate the test class every time" actually inevitable? Maybe one could only rewrite TestSuite and make it behave in a different way. After all it plugis into junit because it's just another implementation of the Test interface, isn't it? That's what I was thinking about when I wanted to provide a spring-integrated test suite: one that does not directly instantiate test objects but asks them to the pre-initialized container.

Posted by Davide Baroncelli on April 08, 2004 at 03:12 PM MDT #

I'm afraid "it's not a bug, it's by design".

Posted by Davide Baroncelli on April 08, 2004 at 03:19 PM MDT #

Well, the problem lies in the design of TestSuite, which is the class one normally uses in order to execute tests. TestSuite looks at the classes you give it, and extracts all testXXX method names, then it instantiates a new class setting its "name" attribute to the "testXXX" method name. When the "run" method will be called on that class, that name attribute is used in order to retrieve the method with reflection and execute it. Actually, the design is quite complex, and the general feeling it gives is that the same thing could be done in a more clean way... But what I don't understand is: for what I know in Junit, one could simply reimplement TestCase and TestSuite with classes that implement the Test interface, and we would have a totally different JUnit with different rules, but just as integrated with the ides as the current is (as long as the ides use the public Test (and TestResult) interface. So, (nearly) everything should be possible, as long as "replacing the custom JUnit behaviour" is the matter. Am I wrong?

Posted by Davide Baroncelli on April 08, 2004 at 05:12 PM MDT #

I investigated about 5 minutes into looking at TestSetup as described in Pragmatic Unit Testing. They had an example where the TestCase would call setUpOnce() and tearDownOnce() methods. I couldn't get it working, so I figured to go the easiest route. It works - which is more important than anything.

The design I'm using (loading applicationContext.xml in setUp()) is actually something I got from Spring's PetClinic app. I (personally) feel it's important to use Spring's wiring abilities in my unit tests, rather than re-wiring them myself - or what am I testing? Method calls and return values? Those seem to simple to really need testing.

I agree that it would be cool to dynamically mock my dataSource, but it's really not that hard to use HSQL or MySQL to do the real thing. That being said - speeding up my unit tests is one of my primary concerns in the next few months. I'm sure mocking will help that. Therefore, my quest for knowledge continues.

It would be cool if you could somehow tell Spring to use a Mock programmatically in your unit test and have it wire that instead of what's in the applicationContext.xml. Maybe you can and I just need to be enlightened.

Posted by Matt Raible on April 08, 2004 at 06:10 PM MDT #

I thank u greatly foryour good information . And as i'm A teacher of english in the Middle east I need more

Posted by essam on February 19, 2006 at 10:02 AM MST #

protected static ApplicationContext ctx = null; // Matt's tip
private static int countTestCases = 0;
 
protected void setUp() throws Exception {
	super.setUp();
		
	if(countTestCases == 0) {
		log.info("oneTimeSetUp()");
		String [] files = 
		{
			"commons-context.xml",
			"jdbcDao-context.xml"
		};
		ctx = new ClassPathXmlApplicationContext(files);
		
		// do some setup

		countTestCases = this.countTestCases();
	}
}

protected void tearDown() throws Exception {
	--countTestCases;
	if(countTestCases == 0) { // no more tests, tear down now
		log.info("oneTimeTearDown()");
		
                       // do some tear down
	}
}

Seems like this was not so good idea after all. I'm sure it worked yesterday, but that was before I rearranged a lot of code. Anyway, I came up with another solution. Using reflection and a filter search for spesific methods (prefix 'test') I am able to count the tests to run for each case. This is how mye classes is linked to each other. SpringTestCase <- DatabaseTestCase <- JdbcDaoTest

The SpringTestCase

public abstract class SpringTestCase extends TestCase {
	private static Log log = LogFactory.getLog(SpringTestCase.class);
	
	// Setting ApplicationContext to static so the system can bypass the setUp run for each test! Tips from Matt Raible
	// More info at http://raibledesigns.com/page/rd?entry=make_your_junit_tests_run 
	protected static ApplicationContext ctx = null;	
	public static int countTestCases = 0;
	protected String [] files = null; 
	
	protected void setUp() throws Exception {
		if(countTestCases == 0) {
			springInit();
			oneTimeSetUp();
		    if(log.isDebugEnabled())
		    	log.debug("Test Case cout = " + countTestCases );
		}
	}
	
	protected void tearDown() throws Exception {
		--countTestCases;
		if(countTestCases == 0) {
			oneTimeTearDown();
		}
	}
	
	/**
	 * Anything that should be ran only once (test start) can be put here
	 * @throws Exception
	 */
	protected void oneTimeSetUp() throws Exception {
		log.info("oneTimeSetUp()");
		
		// do something like insert test data into database
	}

	
	/**
	 * Anything that should be ran only once (test end) can be put here
	 * @throws Exception
	 */
	protected void oneTimeTearDown() throws Exception {
		log.info("oneTimeTearDown()");

		// do some one time tear down
	}

	/**
	 * Please add configLocations to property files here to make Spring work.
	 *
	 */
	protected void setUpConfigLocations() {
	
		
	}
	
	private void springInit() throws Exception {
		log.info("Configuring spring");
		try {
			setUpConfigLocations();
			if(files == null)
				throw new NullPointerException("Please declare spring configLocations (property files)");
			ctx = new ClassPathXmlApplicationContext(files);
		} catch(Exception e) {
			log.fatal(e);
			throw e;
		}
	}
	
	/**
	 * Method that counts methods starting with method name prefix
	 * @param prefix the methodname startswith
	 * @param clazz the class under count
	 * @return number spesifying amount of countet methods which name starts with prefix
	 */
	protected int countMethods(String prefix, Class clazz) {
		Method [] methods = clazz.getMethods();
		int counter = 0;
		for (int i = 0; i < methods.length; i++) {
			Method method = methods[i];
			if(method.getName().startsWith(prefix)) {
				counter++;
				log.info(method.getName());
			}
		}
		return counter;
	}
}

The DatabaseTestCase

public abstract class DatabaseTestCase extends SpringTestCase {
	
	private static Log log = LogFactory.getLog(DatabaseTestCase.class);

	protected void setUpConfigLocations() {
		String [] configLocations = 
		{
				"jdbcDao-context.xml",
				"commons-context.xml"
		};
		files = configLocations;
		
	}
}

The JdbcDaoTest

public class ArticleJdbcDaoTest extends DatabaseTestCase {

	private static Log log = LogFactory.getLog(ArticleJdbcDaoTest.class);
	private ArticlesDao dao = null;
	
	protected void setUp() throws Exception {
		super.setUp(); // important to do this!
		dao = (ArticlesDao)ctx.getBean("articleDao");
	}
	
	protected void oneTimeSetUp() throws Exception {
		super.oneTimeSetUp();
		countTestCases = countMethods("test", ArticleJdbcDaoTest.class);
	}
	
	// All tests below here
}

I'm sure there is possible to optimise this a lot, but I think I will stop here and I have used way more time figuring how to pass this problem anyway.

Posted by Ronny Næss on September 07, 2006 at 10:44 AM MDT #