Much of the technologies above do not or will not need an introduction if you already know them or can read them from the links above.

More over today’s article is more about how we can use all the three selenium, ant and junit to come up with an automated solution for regressive testing.

Please refer to the documentation links above for the basic knowledge on any of the used tools.

I am assuming that you know how to record a test in selenium if you dont then go here

Now that you do know how to record and save the tests simply save them in any directory structure you like as long as they follow the right package convention. like com.foo.bar
this would mean the file should be in directory like com/foo/bar. Conventionally and logically today that is how the TestCase is compiled through the ant script. If the package is not the right path then compile time errors will occur.

My calling target for running the whole procedure should look like this

< target name="build_tests" depends="clean, compile, start-server,  tests, stop-server" / >

Details of the depending targets are as follows.
clean: would clean the entire build directories etc to make sure nothing from our past is carried forward into the future.

compile: should compile

start-server: should start the selenium server.

tests: should run the selenium tests.

stop-server: should stop the selenium server once all tests have been executed.

How to start a selenium server from Ant?

    < target name="start-server" >
        < java jar="lib/selenium-server.jar" fork="true" spawn="true" >
            < arg line="-timeout 30" / >
            < jvmarg value="-Dhttp.proxyHost=proxy.proxyhost.com" / >
            < jvmarg value="-Dhttp.proxyPort=44444" / >
        < / java >
    < / target >

The target above is simply taking the selenium-server.jar which is in the classpath and running the main-class from it. the proxy parameters are optional.

How to stop the server from Ant?

 < target name="stop-server" >
        < get taskname="selenium-shutdown"
            src="http://localhost:4444/selenium-server/driver/?cmd=shutDown"
            dest="result.txt" ignoreerrors="true" / >
        < echo taskname="selenium-shutdown" message="DGF Errors during shutdown are expected" / >
    < / target >
 

The selenium server starts on port 4444 by default and to tell it to shutdown is simple, the command in the src is passed to it. cmd=shutDown
That should just shutdown the server.

Executing the test cases?
Selenium Test cases are Junit tests cases and that’s how they are treated in this tutorial.
Thus some of you will be very much familiar with the ant targets junit and junitreport. However I will describe how the following is working.
the following target will run the selenium tests and print a summary report to the ${dir}
The includes and excludes, simply tell the target which files to include or exclude while running the test cases. This is typically done when you don’t want some tests cases to be included or your source for tests and the application are in the same directory and you only want to include something like Test*.class.

  < target name="tests" depends="compileonly" description="runs JUnit tests" >
    < echo message="running JUnit tests" / >
    < junit printsummary="on" dir=".." haltonfailure="off" haltonerror="off" timeout="${junit.timeout}" fork="on" maxmemory="512m" showoutput="true" >
      < formatter type="plain" usefile="false" / >
      < formatter type="xml" usefile="true" / >
      < batchtest todir="${testoutput}" filtertrace="on" >
        < fileset dir="${src}" >
          < includesfile name="${tests.include}" / >
          < excludesfile name="${tests.exclude}" / >
        < / fileset >
      < / batchtest >
      < classpath >
        < pathelement path="${classes}" / >
        < pathelement path="${build.classpath}" / >
      < / classpath >
    < / junit >

The following will take the formatted output from the lines above and generate a report out of it in xml and html and place the results in the ${reports}/index.html
A sample Junit test report might look like this.

   < echo message="running JUnit Reports" / >
   < junitreport todir="${reports}" >
      < fileset dir="${reportdir}" >
        < include name="Test*.xml" / >
      < / fileset >
      < report format="frames" todir="${reports}" / >
    < / junitreport >
    < echo message="To see your Junit results, please open ${reports}/index.html}" / >
  < / target >

In general you can add all of this to your nightly build through any of the CI servers like Cruise Control. Also as a general practice you will need to do a little more then just executing this target every night depending on your application. For instance cleaning up of resource centers like Databases etc.

I used the following to generate XML from sqlplus:

 select dbms_xmlgen.getxml('select * from user') from dual; 

Output:

< ROWSET >
 < ROW >
  < TNAME >Employee< / TNAME >
  < TABTYPE > TABLE < / TABTYPE >
 < / ROW >
< / ROWSET >

Lets see how that is done here.

1. First lets create a OneListener class that should be able to listen to ActionEvents and also be able to add Commands to itself. Please refer to my previous post on Command,Singleton if you would like to see more about this patterns and there usage.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

package com.shaafshah.jmenus;
 
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.util.ArrayList;
 
import javax.swing.AbstractButton;
 
// Implements the ActionListener and is a Singleton also.
 
public class OneListener implements ActionListener{
 
	private static OneListener oneListener = null;
 
	// Holds the list of all commands registered to this listener
	private ArrayList<Command> commandList = null;
 
	// A private constructor
	private OneListener(){
		commandList = new ArrayList<Command>();
	}
 
	// Ensuring one instance.
	public static OneListener getInstance(){
		if(oneListener != null)	
			return oneListener;
		else return oneListener = new OneListener();
	}
 
	// Add the command and add myself as the listener
	public void addCommand(Command command){
			commandList.add(command);
		    ((AbstractButton)command).addActionListener(this);
	}
 
 
	// All Events hit here.
	@Override
	public void actionPerformed(ActionEvent e) {
		((Command)e.getSource()).execute();
	}
 
}

In the above code, the addCommand method adds the command Object and adds a listener to it.
Now how is that possible.
Basically because I am categorizing my UI objects as Commands with in the system having some UI. And I am also assuming that these commands are Currently AbstractButton i.e. JMenuItem, JButton. Lets have a look at the Command Interface and its Implementation.

1
2
3

public interface Command {
	public void execute();	
}

And the implementation, note that the Command is an interface where as the class is still extending a UI object.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

import javax.swing.JMenuItem;
 
public class TestCmd extends JMenuItem implements Command{
 
	public TestCmd() {
		super("Test");
		OneListener.getInstance().addCommand(this);
	}
 
	@Override
	public void execute() {
		System.out.println("HelloWorld");
	}
}

Personally don’t like calling the OneListener in the constructor of the class but just for the sake of simplicity of this post I have left it that way. There are many different ways to omit it.

So the TestCmd is a JMenuItem but is also a Command and thats what the OneListener understands.
As this commads Listener is also OneListener all ActionEvents are thrown there and from there only the Command.execute is called on.

So now you dont have to worry about what listeners are you in. The only thing you know is that when execute is called you need to do your stuff.

You can download the code from Here.

Hope this helps.

As I recall it was like this when they were teenagers
Few teams working on different modules of same application, deployed together.
No build process formalized
No builds except for the ones that need major milestone deployments.
No feedback, reports, reviews etc.

So virtually there was no build eco system.

Which meant hideous amounts of communication, tons of trouble shooting, last minute show stoppers, And extermely unhappy end users/stake holders.

So what exactly was going wrong.

There was no Configuration Control i.e. No way to figure out the changes that will be part of the release and no controls to include or exclude them.
No Status accounting i.e. No feedback or status of anything as a whole product.
No management of Environment meant no one knew what hardware/software they were using and sometimes why?
No team work whatsoever meant no guided processes, reviews or tracebility of issues and pitfalls.

So virtually a release day was the doomsday!

It took some time for developers to realize that how important the following were.
* Configuration identification – What code are we working with?
* Configuration control – Controlling the release of a product and its changes.
* Status accounting – Recording and reporting the status of components.
* Review – Ensuring completeness and consistency among components.
* Build management – Managing the process and tools used for builds.
* Process management – Ensuring adherence to the organization’s development process.
* Environment management – Managing the software and hardware that host our system.
* Teamwork – Facilitate team interactions related to the process.
* Defect tracking – Making sure every defect has traceability back to the source

And after all it takes some time but the day to day flow looked like the figure below.

Build Management

Importantly
Developers are distributed on different locations in different teams.
There is an SCM team that takes care of the SCM activities i.e. Configuration Identification, Control, Build Management etc.
There is one single repository for all developers.
A process is defined for Product integration and its checked whenever some one checks in.
And hourly build is dont to check the sanity of the system with the unit tests.
A Nightly build is done with all full blown unit tests, coverage reports, Automated tests and installers and upgrades.
More over all of the above is shown on an FTP/HTTP site. FTP for installer/binary/archive pickup and HTTP for detailed view of builds/feedbacks etc.

All of the above meant strength and health of the build eco system. And more trust in the system that it will report failures along the way.

Our approach to SCM enables unlimited and adaptable process models, which are ideally suited for parallel, distributed, and agile software development. Using state of the Art technologies from various vendors to automate processes such as branching, merging, build, and release keeps you a click away from software delivery.

The real matter then is the sanity of your application and that’s the challenge we all need to address. We can have cute products right of the shelf to get it up and going but the whole challenge lies in the statement “up and going”. It takes a ton of energy and effort to come up with the right process and the right tool. I have not seen alot of CI projects failing strictly. But I do have seen extra efforts into things that should not be really there. failure would then mean the amounts of efforts spent on doing not so trivial stuff and on the other end if you are spending alot of time doing the major flows then definately something is wrong.

Automation does solve most parts of the problems but things that really need to be taken care of to get it right in the sweet spot are the ones Martin Fowler described in one of his articles.

* Maintain a Single Source Repository
Keep everyone together, at the end of the day we all work together dont we?

* Automate the Build
Automation of the build helps you.

* Make Your Build Self-Testing
Self testing build tells you exactly what you did and what you broke. So I can come up with this statement to my Lead. “If I commit this, it might break alot of stuff”. Well Sir, try running the Unit Test, You will know for sure! But then again honesty on the test cases really doest matter!

* Everyone Commits Every Day
Typically in a Agile environment helps alot, and forces you not to break the build. Better organization I must say.

* Every Commit Should Build the Mainline on an Integration Machine
Sanity checking of your commits. So often we commit without realiazing that we break something else.

* Keep the Build Fast
I usually commit before leaving for home. It helps great deal when you get the feedback within 5 mins. kind of a benchmark but depends.

* Make it Easy for Anyone to Get the Latest Executable
Keep all the build results and one sharable place. We did that on one of the http servers some time back

* Everyone can see what’s happening
Importantly that all results are published for all of us to know.

* Automate Deployment
Deployment automation means that my buddy X on the other side doesnt screw up the server for even a 1 min. Only deploys when build successfull.

Hope this helps.

Resources:

http://martinfowler.com/articles/continuousIntegration.html

1
2
3
4

 public TestReadFileFromJar() throws FileNotFoundException, IOException {
        InputStream is = getClass().getResource("txtData/states.properties");
        read(is);
}

In the case above txtData is placed in the jar on the root. Remmember to add the path with the /

You want to parameterize objects to perform an action
You want to specify, execute and queue requests at different times.

Just to quickly start you need a command object, An interface will keep it easy going in this case, thus providing you with the option of extending other classes e.g. Swing MenuItem or Button.
Below the execute Method is the one invoked to do something when this command is called or asked to do its stuff.
Where as the getCommandName is assumed as a unique name how ever I am sure we can always come up with a better implementation for uniqueness.

1
2
3
4
5
6

public interface Command {
 
    public void execute();
    public String getCommandName();
 
}

And example implementation of the Command should look as follows
A Command Name, and and execute Method to tell what happens when this command is called.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public class ForwardCmd implements Command {
 
   private String COMMAND_NAME = "Back";
 
   public BackCmd() {
       super();
   }
 
   public String getCommandName() {
       return COMMAND_NAME;
    }
 
    public void execute() {
        System.out.println("Your wish, my command");
    }
}

The command manager is the controller in this case. It registers command objects. the “registerCommand” will simply take a command and store it in a list or something alike. This means you could load it out of a jar file, or an xml or path and just pass the object to the “registerCommand” AS a command offcourse.

the “execute” Command will simply execute the Command passed to it.

And the “getCommand” returns a command by looking up a COMMAND_NAME. So if you provide a name to it through you system it should give you an object of type Command and simple pass it to execute. Again this would be a controller logic and not the client one.

1
2
3
4
5
6
7

public abstract class AbstractCommandManager {
 
    public abstract void registerCommand(Command command);
    public abstract Collection getAllCommands();
    public abstract void execute(Command command);
    public abstract Command getCommand(String name);
}

Adapter a structural pattern will let you adapt to a different environment. The joining between different environment is called Adapter. Thus basically giving others the interface that they expect or vice versa when your program becomes the client.

For example the following class expects that the implementing class should be implementing all three methods.

1
2
3
4
5
6
7
8
9

public interface RecordListener {
 
public void eventPrePerformed(RecordEvent recordEvent);
 
public void eventPerformed(RecordEvent recordEvent);}
 
public void eventPostPerformed(RecordEvent recordEvent);
 
}

So lets say our implementing class is a rude one and only wants to implement one method. What do you do as an API designer. hmmm

Thats where we step in with the Adapter.

1
2
3
4
5
6
7
8
9
10
11
12
13

public abstract class RecordAdapter implements RecordListener {
 
public void eventPrePerformed(RecordEvent recordEvent) {}
public void eventPerformed(RecordEvent recordEvent) {}
public void eventPostPerformed(RecordEvent recordEvent) {}
 
}
 
public MyAdapterImpl extends RecordAdapter{
 
public void eventPerformed(RecordEvent recordEvent){}
 
}

Now the only thing left to do is use the adapter. And override any method that you might need .

1
2
3
4
5
6
7
8
9

public MyClientClass {
 
public MyClientClass(){
 
this.addRecordListener(new MyAdapterImpl());
 
}
 
}

So today I am talking about the Abstract Factory pattern. Its not an “abstract” class or object that you call a pattern. But its a Factory of facotries and that is what exactly makes it so much wordingly abstract. Having “abstract” classes is there but just some other side of the coin.

When should I use an Abstract Factory:

• Independence of how products are created, composed or represented
• Should be configurable with one of the multiple families or products
• You need enforcable constraints for the products used as a group
• You need to reveal only the interfaces of products and not thier implementation as part of a bigger picture.

So lets begin with the fun.

This is how I plan to implement it:
Has A:
Product has a Specification
Factory has a Product
FactoryManager has FactoryConstants
FactoryManager has ComputerFactory

Is A:
BFactory is a ComputerFactory
AFactory is a ComputerFactory

Not shown.
ProductA is a Product
ProductB is a Product

Diagram:

AbstractFactory

Creating a simple factory that returns products.

1
2
3
4
5
6
7
8
9

public abstract class ComputerFactory {
 
 public abstract String getName();
 
 public abstract Product[] getProducts();
 
 public abstract Product getProduct(int ProductID);
 
}

Implementation of the ComputerFactory

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

public class AFactory extends ComputerFactory {
 
public String getName(){
return "A";
}
 
public Product[] getProducts(){
return null;
}
 
public Product getProduct(int productID){
switch(productID){
case 1:
return new ProductA();
 
case 2:
return new ProductB();
 
default:
throw new IllegalArgumentException("Sorry you hit the wrong factory, we closed down in 1600 BC");
}
}
}

A register base for factories. Refer to the main method for use later in this post.

1
2
3
4
5
6

public interface FactoryConstants {
 
 public int A = 1;
 public int B = 2;
 
}

The main Entrant class. the Factory Manager that will give the ComputerFactory resultant. Its assumed to be a Singleton as it registers as a Creator in the system (assumption).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

public class FactoryManager{
 
 private static FactoryManager factoryManager = null;
 
 private FactoryManager(){
 
 }
 
 public static FactoryManager getInstance(){
  if(factoryManager != null){
   return factoryManager;
  }
  else return factoryManager = new FactoryManager();
 }
 
 public ComputerFactory getFactory(int factory) throws IllegalArgumentException{
 
  switch(factory){
   case FactoryConstants.A:
   return new IBMFactory();
 
   case FactoryConstants.B:
   return new SUNFactory();
 
   default:
   throw new IllegalArgumentException("Sorry you hit the wrong factory, we closed down in 1600 BC");
  } 
 }
}

A main method to test the AbstractFactory

1
2
3
4
5
6
7

 public static void main(String args[]){
 
  System.out.println(FactoryManager.getInstance().getFactory(FactoryConstants.A).getName());
  System.out.println(FactoryManager.getInstance().getFactory(FactoryConstants.B).getName());
  System.out.println(FactoryManager.getInstance().getFactory(3).getName());
 
 }

You can find the complete code listing here:
AbstractFactory source