Saturday, June 11, 2011

Flexible validation mechanism in test automation using decorator pattern

Today, I like to talk about having flexible way of validation logic in your test automation.

Are you familiar with design pattern called "Decorator?" I don't want to spend a lot of time explaining what it is in this post, so you can search Decorator pattern on the web (there are a lot of them).

Basically, what it is is that having mechanism of code to process what is responsible for currently object and trigger the next object in line to process its own logic. (you really need to understand what decorator pattern is if you don't know it)

Now, we can apply this pattern to validation logic.
Normally, in your automation there are several different kinds of validations you would put to conclude that the test passed or not. As the automation gets more complicated and scale, you would not want to have one validation class that handles all the validation/verification for all test cases. New and different kind of validation/verification logic might need some other process that previous validation logic not required. So how do you flexibly add new verification logic in to your automation? There will be several ways to handle this but one of the solution is using decorator pattern.

Let me go though the concept and I will provide some example of that.

  1. Define a base abstract class/interface (i.e. Validator) and defined a constructor that takes Validator object and  method called validate().
  2. Now create derived class call Validator1, Validator2,.... that inherit/implements the base class/interface
  3. In Validator1 and Validator2 class implement a private method that process its own logic and have its validate() method to call that. 
  4. After #3, call validate() method of Validator instance variable
The simple code would look like this.

public abstract class Validator
{
    private Validator m_validator;
    
    public Validator(Validator validator)
    {
        m_validator = validator;
    }
    
    public abstract validate();
}


public class Validator1 extends Validator
{
    private Validator m_validator;

    public Validator1(Validator validator)
    {
        m_validator = validator;
    }
 
    public validate()
    {
        validator1logic();
        m_validator.validate();
    }

   private void validator1logic()
   {
        //execute the logic here
    }
}

You can see the idea here. Each derived Valdiator class will have its own logic and execute validate() method whatever Validator object passed.

Now you have several derived Validator classes and you can mix and match any combination as you wish.

Here is the sample code

// 3->2->1 in order
Validator myValidator = new Validator3( new Validator2 ( new Validator1(null)));
myValidator.validate();

// just 2 and 1
Validator myValidator = new Validator3( new Validator1(null));
myValidator.validate();

// 1,2 3
Validator myValidator = new Validator1( new Validator2 ( new Validator3(null)));
myValidator.validate();

1 comment:

Rachael@Faucet Valve said...

These sound delightful.Your contents are progressing with days keep it up guys.