Arrange Act Assert Pattern

It’s a pattern for arranging and formatting unit test methods. The main benefit of this pattern is that it clearly separates what is being tested from setup and verification steps.

The below are the steps defined in this pattern.

1. Arrange all necessary preconditions and inputs.
2. Act on the object or method under test.
3. Assert that the expected results have occurred.

Example unit test method is given below.

@Test
 public void testAdd() {
    int a = 10;
    int b = 10;
    		
    int c = Calculate.add(a, b);
    
    assertEquals(20, c);
 }

The above method is used for testing the “add” method defined in Calculate.java. In the first 2 lines, the input parameters(Arrange) are defined and in the 3rd line, the add method is getting called with the given input parameters(Act) and in the 4th line, the result value is getting verified(Assert).

SPECIAL CASE PATTERN (Fowler)

Most of the time, we would throw an exception to handle an unexpected behavior. In some cases, if the caller code does not want to handle that error and follow a default approach, then we can use “Special Case Pattern”. Refer the below example to know how to do that.

Assume that we have class “BillingDao” contains methods to fetch the billing details of an employee. “getBillingDetails” is a method returns the billing details of an employee by his/her company name. Assume that if it does not find the billing details, then it will throw “BillingDetailsNotFoundException “. So the client code has to handle that scenario. We can refactor this code with “Special Case Pattern”

float rate = 0.0f
try {
  BillingDetails billingDetails= billingRateDao.getBillingDetails(employee.getCompany());
  rate+= billingDetails.getRate();
} catch(BillingDetailsNotFoundException e) {
  rate += getDefaultBillingRate()
}

We will create a new class “DefaultBillingDetails” which implements “BillingDetails” and we can specify the default billing details in it.
Then we can update the “BillingRateDAO” to return the instance of DefaultBillingDetails instead of throwing an exception. I have not given the BillingRateDAO code here but assume that it return an instance of DefaultBillingDetails.

The modified code will look like below.

BillingDetails billingDetails= billingRateDao.getBillingDetails(employee.getCompany());
  rate+= billingDetails.getRate();
....
.....
public class DefaultBillingDetails implements BillingDetails {
 public int getRate() {
 // return the per default rate
 }
}

Build Operate Check – Acceptance Pattern

Build operate Check is one of the acceptance pattern. So its good that to follow this pattern while creating the Junit test cases.

The first step is to build the input data and hold it in memory, then execute it on the actual code which means call/invoke the code to operate on that data. Finally check the results of that operation.

Please refer the below example.

package com.dao.test;

import org.junit.Test;
import static org.junit.Assert.assertNotNull;
import com.dao.ContactDAO;
import com.model.Contact;

public class ContactDAOTest{
    @Test
    public void testCreateContactData() throws Exception {
        //Build the test data
        Contact contact = buildContactData("bala","dublin");
        //Call the ContactDAO to create the contact information. Assume that 
        //Create() returns an id after the successful creation of the contact in DB
        String id = new ContactDAO().create(contact);
        //check the id and make sure that its not null/blank
        assertNotNull(id);
    }

    private Contact buildContactData(String name, String city) {
        Contact contact = new Contact();
        contact.setName(name);
        contact.setCity(city);
        return contact;
    }
}

package com.model;
public static class Contact {

        private String id;
        private String name;
        private String city;

        public String getId() {
            return id;
        }

        public void setId(String id) {
            this.id = id;
        }

        public String getName() {
            return name;
        }

        public void setName(String name) {
            this.name = name;
        }

        public String getCity() {
            return city;
        }

        public void setCity(String city) {
            this.city = city;
        }
    }

Post Redirect Get Pattern

This is one of the web design pattern which is used to prevent the double form submission issue.

In the old days, when we design an application with JSP’s, we often face double form submission issue. So one of the best way to avoid this to disable the submit button as soon as the submit button is clicked. But if we show the result on same JSP page, then if the user refreshes the browser, then the form will be submitted again which cause some undesirable issues.

To avoid these kinds of errors/issues, we may need to change the API/server code to validate the request and some custom states. So it requires some unnecessary state maintenance in the server side.

Post Redirect Get pattern comes to the rescue in this kind of situation. Please refer the below diagram.

 

Here in this case, As soon as the user submits the form, the server does the operation on the backend and also forces the browser to redirect to a confirmation page. So if the user refreshes the confirmation page, then it would not have any impact as it will not do any operation other than showing the confirmation page.

But we have to keep in the below points along with this pattern.

1. Disable the Submit button as soon as the user clicks on it
2. If the server takes long time to respond back with the confirmation page and user tries to stop the browser and refresh the page in the mean time, then it will cause some other issues. So to handle these kind of issues, we have to either maintain some state and by checking this we can prevent the double submission issues.