Using Slim Scenario fixtures this can be implemented fairly easy. Scenarios are Slim tables that can be called form other Slim tables. For a step by step tutorial on how to apply Scenarios I recommend watching Bob Martin’s screencast.

With a few additions to Bob Martin’s video you can use that test for both API and UI.

Lets say we have the following BDD style test:

given a current maximum capacity of 2 and 1 items already planned
then I can lower the maximum capacity to 1
then I can not lower the maximum capacity to 0

Using scenarios this would end up in the following FitNesse markup:

!|scenario|given a current maximum capacity of |maxCapacity| and |itemsPlanned| items already planned|
|set maximum capacity to|@maxCapacity|
|plan|@itemsPlanned|items|

!|scenario|then I can lower the maximum capacity to|newMaxCapacity|
|ensure|set maximum capacity to|@newMaxCapacity|

!|scenario|then I can not lower the maximum capacity to|newMaxCapacity|
|reject|set maximum capacity to|@newMaxCapacity|

!|script|MaxCapacityApiDriver|

!|script|
|given a current maximum capacity of |2| and |1| items already planned|
|then I can lower the maximum capacity to |1|
|then I can not lower the maximum capacity to |0|

And the fixture would look like this:

public class MaxCapacityApiDriver {

	private Capacity capacity = new Capacity();

	public boolean setMaximumCapacityTo(int max) {
		try {
			capacity.setMax(max);
			return true;
		} catch(MoreItemsThanCapacityException e) {
			return false;
		}
	}

	public void planItems(int items) {
		for(int x=0; x<items; x++) {
			capacity.plan();
		}
	}
}

Now if we look at the example we could also apply this to our maintenance user interface where the admin can actually change the max capacity.

Using selenium-rc this can be implemented fairly easy. I choose to keep the FitNesse pages the same, the only thing I change is the driver that is used.

Step 1. Extract Scenario

we do not want to duplicate the scenarios so we extract the scenarios to a seperate page. We can then include this page using the !include directive in FitNesse.

Our test FitNesse markup now looks like this:

!include ScenarioPage

!|script|MaxCapacityApiDriver|

!|script|
|given a current maximum capacity of |2| and |1| items already planned|
|then I can lower the maximum capacity to |1|
|then I can not lower the maximum capacity to |0|

Step 2. Extract Test

Wait a minute. We also want to reuse our BDD style test. Let’s do the same trick as we did using the ScenarioPage.

After extracting the Test our FitNesse markup looks like this:

!include ScenarioPage

!|script|MaxCapacityApiDriver|

!include TestPage

Step 3. Implement Driver

Now all we have to do is implement the UI driver.

!include ScenarioPage

!|script|MaxCapacityUiDriver|

!include TestPage

This is how the fixture code could look like using selenium-rc, I left out some plumbing for readability

public class MaxCapacityUiDriver {

	private Selenium selenium;

	public boolean setMaximumCapacityTo(int max) {
		selenium.open("/capacity/change");
		selenium.type("maximum", String.valueOf(max));
		selenium.click("changeMaxButton");
		selenium.waitForPageToLoad(TIMEOUT);
		return selenium.isTextPresent("successfully changed capacity to: "
				+ max);
	}

	public void planItems(int items) {
		selenium.open("/items");
		for (int x = 0; x < items; x++) {
			selenium.click("planItem");
			selenium.waitForPageToLoad(TIMEOUT);
		}
	}
}

Using FitNesse scenarios and extracting pages to include them is very handy when you want to re-use some tests. Please keep in mind that it is not wise to test your application code through your UI, so apply this carefully. I tend to pick only a few scenarios to see if the UI and API communicate properly.

1. Start with the acceptance tests for your feature.

This is the most important one of all. According to its definition “In TDD each new feature starts with writing a test”[1]. Since a feature is always something that the user wants you must, by definition, start with the tests for your user stories. Now-a-days that is called Acceptance Test-Driven Development, but that is just toying with words. It is just TDD as it is meant to be IMHO.
A good way to write your tests is to use examples in BDD style: Given, When, Then. Since examples are concrete they are usually understandable for both User and Programmer. I tend to use FitNesse as framework to automate these tests right away. Here is an excellent video tutorial by Bob Martin describing how to create BDD style tests in FitNesse.

2. Refactoring is part of the job.

I see a lot of Red-Green, Red-Green, Red-Green out there. Refactoring is actually the biggest step in the whole TDD cycle IMHO. This is where you do the actual design of your system. You created a test, made it work, now it is time to take a step back and make it right. Maybe this requires a (small) design session in front of a whiteboard with your colleagues, or maybe you can do it on a napkin. It doesn’t really matter how you do it, as long as you do it. Especially in the first couple of iterations of your project the refactoring step can be quite long in my experience. That is not so hard to grasp since the foundations of your system are created then.
TDD is about helping you to come to a good design for your system. Since the tests are in fact the first clients of your system they help you focus on what your system should do, and how it will be used.

3. Formulate your tests in high-level terms.

I got this tip on the FitNesse maillinglist from Rick Mugridge. This was a real A-ha erlebnis for me. It means that you avoid using implementation details in your tests. For instance if you are going to test a UI, the “wrong way” to define your test is:

open page myapp.com
type "Lars" into field "Name"
type "secret" into field "password"
click button "login"

The “right way” is:

given a logged in user "Lars" with password "secret"

Why is this important?
First of all the “wrong way” example is not refactor safe. What if we change the name of the fields, or split it into 2 pages? Then that would require to change our tests. And one of the biggest advantages of (acceptance) tests is that you don’t need to change them when you do (small) refactorings.
Secondly when you define your tests the “right way” they can be used for both UI testing, API testing, SQL testing etc. Since the tests do not expose implementation details, we can use the definition for multiple implementations. Using FitNesse scenario’s you could simply reuse your test page and just use a different Fixture that implements the actual test in the preferred technology (SQL, Java, Webservice, Selenium etc). In my next blog I’ll show you how to do that.

4. Keep the database out as long as possible.

When designing your system with TDD you will do a lot of refactorings, especially in the first iterations. I you use a database from scratch that will only slow down the process since databases aren’t as refactorable as for instance Java code. Secondly in 99% of the applications the database is only a datastorage and the performance impact is not really an issue, meaning the database won’t impact your design in order to meet those performance criteria. So if it does not contribute to your design why drag it with you all the time? So in the first iterations I tend to use a hashmap or so as database implementation. Now-a-days it is relatively simple to map your object model to a relation model anyway using tools as Hibernate.

So to take full advantage of TDD start out with your User Story tests and define them on a high level (using Given, When, Then). When you made it work, refactor it to a good design. It helps when you keep the database out as long as possible, because databases slow down the refactoring process.

Lars

[1] http://en.wikipedia.org/wiki/Test-driven_development#1._Add_a_test

1. First locate the Subversion config file. Most probably you will find it at ${HOME}/.subversion/config. In the file locate the global-ignores line and add the patterns you wish to exclude from the import, typically these are generated files like .class files etc. For instance in a Maven, Java, Eclipse project you would put: global-ignores = target .classpath .project .settings

2. Run svn:import [PATH] URL. Now everything you put in the global-ignores line is excluded from the import.

3. You still do not have a working copy though since svn:import does not replace the local files with the working copy. To achieve this you can run svn co --force URL [PATH]

4. Now the files you put in global-ignores on your local file system are not ignored on your colleagues machine when they do a fresh checkout. So they could be temped to check-in the generated files. To prevent this you need to add the files to the svn:ignore list of the parent folder using the propset (or propedit) command. To achieve this you first need to comment out the global-ignores line in your config file. Then add the generated files to svn:ignore and check the code in.

This way you can check-in new code into subversion without having to manually remove all the generated files first. It would be nice though if Subversion provided a way to ignore files on import and checkout the code in a single command.

   @Test
    public void shouldSecureAllPagesInAdminPackageExceptTheLoginPage() throws Exception {
        ClassPathScanningCandidateComponentProvider provider = new ClassPathScanningCandidateComponentProvider(false);
        provider.addIncludeFilter(new NonSecuredWebPagesFilter(LoginPage.class));
        Set components = provider.findCandidateComponents("nl.ns.campaigns.admin.web");
        assertEquals(0, components.size());
    }

The idea of this test is that it should not find classes that extend WebPage and that are not annotated with @AuthorizeInstantiation. If we do find one, the test will fail.
The logic match is implemented in a TypeFilter, in this case the custom NonSecuredWebPagesFilter. The code of the TypeFilter looks like this:

    private static final class NonSecuredWebPagesFilter implements TypeFilter {
        private final Class loginPage;
        public NonSecuredWebPagesFilter(Class loginPage) {
            this.loginPage = loginPage;
        }
        public boolean match(MetadataReader metadataReader, MetadataReaderFactory metadataReaderFactory) throws IOException {
            boolean hasAnnotation = false;
            boolean isWebPage = false;
            boolean isLoginPage = false;
            try {
                String className = metadataReader.getClassMetadata().getClassName();
                Class clazz = Class.forName(className);
                isLoginPage = loginPage.equals(clazz);
                isWebPage = WebPage.class.isAssignableFrom(clazz);
                hasAnnotation = clazz.isAnnotationPresent(AuthorizeInstantiation.class);
            } catch (ClassNotFoundException e) {
                throw new IllegalStateException(e);
            }
            return !hasAnnotation && isWebPage && !isLoginPage;
        }
    }

Since the LoginPage does not have to be annotated we exclude it from our search. Only WebPages that are not annotated are returned due to this TypeFilter.

Scanning the classpath has become a piece of cake using the ClassPathScanningCandidateComponentProvider and I am sure there are many more usecases for this class.

- Job Instructions
- Job Methods
- Job Relations
- Program Developement

Job Methods is the one that took my attention. Wikipedia states that Job Methods is

a course that taught workers to objectively evaluate the efficiency of their jobs and to methodically evaluate and suggest improvements. The course also worked with a job breakdown, but students were taught to analyze each step and determine if there were sufficient reason to continue to do it in that way by asking a series of pointed questions. If they determined some step could be done better by Eliminating, Combining, Rearranging, or Simplifying, they were to develop and apply the new method by selling it to the “boss” and co-workers, obtaining approval based on Safety, Quality, Quantity, and Cost, standardizing the new method, and giving “credit where credit is due.”

That sounds a lot like Kaizen doesn’t it? Although TWI was abandoned after the war in the US, its practices were well received and adapted by the Japanese and the Toyota Motor Corporation in particular.

If you want to read more about TWI and the apparent revival it is going through you can read all about it here: http://www.twi-institute.com/. Especially for the Agilist among us it sounds very familiar.

The answer is the maven-antrun-plugin. This plugin allows you to integrate ant tasks in Maven builds. To get the sql files we first create the Ant build.xml that will call the Ant task provided in the hibernate tools

[/xml]

	

	

		
		
		

			
			    
			    	
				
			
			

		
	

[xml]

In the above xml I declared the hibernatetool task via taskdef. Secondly, I created a target called generate-sql that I am going to call from the Maven build. The hibernatetool and hbm2ddl tasks are documented on the hibernate tools page, so checkout that if you need more info on how to configure.
As you can see I am using ${} properties. These are passed in from the Maven configuration. The file hibernate-for-sql-generation.properties contains the Dialect that Hibernate will use to generate the sql file.

Next is the relevant part of the pom.xml. Since I don't want to generate the sql each time I do a Maven build, I added it into a profile:

[/xml]

	generate-sql
	


				org.apache.maven.plugins
				maven-antrun-plugin
				1.3
				
					
						generate-sql
compile
						
							




								
									
								
							
								
						
							run
						
					
				
			
		
	

[xml]

The really interesting part starts from the execution tag. In here I tell the maven-antrun-plugin what to do. As you can see I pass in, amongst other things, the Maven test classpath. The classpath is needed by Ant to locate the org.hibernate.tool.ant.HibernateToolTask. Since I pass in the test classpath I added the hibernatetools jar as a dependency with scope test in the pom.xml.

When you now run mvn compile -Pgenerate-sql it will generate a sql file in the directory target/database. With some minor adjustments you are ready to use the generated file for creating your tables on all environments.

Lars

1. I want to be able to edit classes and views (Wicket html files or jsp’s) and see the results in the browser fast without having to build a war file and manually redeploy.
2. I want to be able to switch between an in memory database, typically a Hsqldb and the real target database (Oracle). Since I am using Hibernate as ORM I also need to be able to switch settings like the hibernate.dialect property to match my database.
3. The WAR file produced should also run on the target application server, JBoss in my case.

Let’s see how Jetty fulfills these requirements.

The example project consist of a webapplication using Spring, Hibernate and Wicket. The target platform is JBoss with an Oracle database.

To get started we first need to add the jetty-maven-plugin in the pom.xml of the war project.

[/xml]

  jetty-maven-plugin
	org.mortbay.jetty
	7.0.0pre3
	
		/example-app
		3
		
			
8090
				0.0.0.0
			
		
	

[xml]

That’s it. When running mvn jetty:run the webapplication is available under http://localhost:8090/example-app. For a complete reference of all possible configuration settings I suggest you read http://jetty.mortbay.org/jetty/maven-plugin/run-mojo.html

Fast redeploying.
In my experience, I have no evidence, Jetty is the fastest starting servlet container out there, especially when you compare it with full blown application servers such as JBoss. JBoss is perfect for production and acceptance environments but when developing I have different needs. This is where Jetty gets a big plus.
Regarding redeploying: By default the jetty-maven-plugin automatically reloads/redeploys the webapplication whenever it detects a change. You can use the scanIntervalSeconds and scanTargets configuration properties to tweak change detection. Downside of this automatic reloading is that it will always reload, even if you are just developing for a couple of minutes and save changes in between. Not only does this consume unnecessary resources, it will eventually lead to full PermGen space which results in an OOME.
A way to counter this is to set the reload option of the jetty-maven-plugin to manual. Now reloading will only occur on a linefeed (hitting enter) in the console where you started jetty.

Switching databases
When developing a webapplication I want to be flexible. I want to be able to connect to a fast in memory database, to the target database and to a database that is for instance on a test machine. How can we achieve this with jetty? In my case I have two local databases: a Hsql database and an Oracle database installed on a VMWare image.
Since my Spring context uses a JNDI configured datasource I need to add those in Jetty as well. For this you need to create set the jettyEnvXml property in the jetty-maven-plugin. This property points to the jetty configuration file, called jetty-env.xml, containing the datasource in our case. But we also need to be able to switch hibernate dialect. Since we are using Spring we have the PropertyPlaceHolderConfigurer in our applicationContext in SYSTEM_PROPERTIES_MODE_OVERRIDE mode. This means that system properties override values defined in the applicationContext or the property file (if any). Together with Maven’s profiles we can now configure the jetty-maven-plugin so we can switch databases as needed.

The relevant parts of our pom now look like this:

[/xml]
...

  jetty-maven-plugin
	org.mortbay.jetty
	7.0.0pre3
	
		/example-app
		manual
                ${jetty.env.file}
		
			
8090
				0.0.0.0
			
		
		
			
				hibernate.dialect
				${hibernate.dialect}
			
		
	

...


		jetty-oracle

			${basedir}/src/test/resources/jetty-env-oracle.xml
			org.hibernate.dialect.Oracle10gDialect
		
	

		jetty-hsql

			${basedir}/src/test/resources/jetty-env-hsqldb.xml
			org.hibernate.dialect.HSQLDialect
		
	

[xml]

The contents of the jetty-env-hsqldb.xml is as follows:

[/xml]



	
		jdbc/example
		
			
				org.hsqldb.jdbcDriver
				jdbc:hsqldb:mem:test
				sa
				
			
		
	

[xml]

Via this configuration we are able to switch between Oracle and Hsqldb by specifying the profile at the commandline. For example mvn jetty:run -Pjetty-hsql in case we want the Hsqldb.

Servlet container compatibility
We are almost there. As said before, the example application is using a JNDI configured datasource and refers to it in the applicationContext using a jee:jndi lookup:

[/xml]

[xml]

When deploying the produced WAR file in JBoss it gives an error saying that jdbc is not bound. To get the application up and running in JBoss as well you to follow the steps as described in http://forums.sun.com/thread.jspa?threadID=626778. This is caused by the fact that not all servlet containers have the same way of registering jndi values.