This is a case study of a top retailer in UK which was following Agile but not all the Agile practices. We will discuss how collaboration between business and engineering team improved using BDD and how it was used to generate automated acceptance tests. We will also discuss how continuous integration was implemented which laid foundation for continuous delivery.

1. Bridging the communication Gap & Continuous Delivery
Case study of a top retailer in UK
Masood Jan
Mazataz Ltd

2. Agenda
 Communication Gap.
 Bridging the Gap.
 Simplifying Automated Functional
& Unit Testing.
 Continuous Integration.
 Path to Continuous Delivery.

3. The Communication
Gap
• The BA/Arch agree with business regarding
stories (epics) and creates HLD/LLD.
• The Developer reads the LLD and sometimes
makes a different set of assumptions to create
code.
• The Tester reads the requirements and may
make a second set of assumptions to create
test plans
• The Developer finishes the story, does the
“Works On My Machine” stuff, and checks in.
• The Testers wait for a build in Test
Environment, usually couple of hours/days.
• If Build was successful tester verifies function
against test plans.
• Identifies defects raises them.
• Developer analyses the defect, debugs to fix it.
• The Testers wait for another build.

4. The Result
 Late feedback.
 Confusion during development and
testing.
 Change of requirements not clearly
propagated.
 Surprises.

5. What was needed
 Focus on development and delivery of
Prioritised, Verifiable Business Stories.
 Focus on providing a common vocabulary that
bridges the gap between Business and
Technology.
 Focus on exposing business rules to be reviewed
by stake holders.
 Focus collaboration between
Developers, Testers, Architects, BA’s and the
Business.
 Make it easy to Automate functional testing.

6. What did we do
We behaved ourselves!

7. How did we do that
 Have Small Vertical stories of Business Value.
 Agree & Document business rules.
 Agree & Document the behaviour.
 Agree how story would be accepted.
 Create executable scenarios for each behaviour.
 Given, When and Then.
 Develop the behaviour and verify the scenarios.
 Show completed scenarios to Truth.
 React to feedback.
We synched up!

8. The Result
 Business and engineering team
speak same language.
 Quick Feedback.
 Requirements changes were easily
communicated.
 No surprises.

9. What tools we used ?
 JBehave (Java)
 Selenium for web applications.

10. Why JBehave?
 Java, all the teams were aware of
it.
 Built on JUnit framework.
 Scenarios written in text file.
 Given , When & Then
annotations.
 JBehave code generator
(custom).
 Integrates well on CI.

11. The JBehave Framework

12. See it in Action !
 Simple Login Story

13. Example Story
Story Title: Login to the Customer Service Centre (CSC)
So That: I can resolve customer issue with an order
As: A user
I Need: To Login to the CSC
Acceptance Criteria:
1. I should be able to login using valid username and
password
2. I should not be able to login using invalid username or
password

14. Defining Scenarios
Scenario 1: Valid Login
Given the user is on Login Page
When the user types user name service
And the user types password service
And clicks login button
Then the user should be logged in
And the user should see a message,
Welcome, Service Administrator.
Scenario 2: Invalid Login
Given the user is on Login Page
When the user types user name wrong
And the user types password wrong
And clicks login button
Then the user should not be logged in
And the user should see a message,
Invalid Username or Password.

15. JBehave Code Generator
• Create valid_login.scenario file in eclipse.
• Copy login scenario into it and save.
• Right click on this file and choose
• JBehaveCodeGenerator
• Generate Code
• This will create two java files
• ValidLogin.java
• ValidLoginSteps.java

16. ValidLogin.java
public class ValidLogin extends
Scenario {
public ValidLogin () {
super(new ValidLoginSteps());
}
}

17. ValidLoginSteps.java
public class ValidLoginSteps extends Steps {
@Given("the user is on the Login Page")
public void theUserIsOnTheLoginPage() {
throw new RuntimeException("Step not yet implemented");
}
@When("the user types username $username")
public void theUserTypesUsername(String username) {
throw new RuntimeException("Step not yet implemented");
}
@When("the user types password $password")
public void theUserTypesPassword(String password) {
throw new RuntimeException("Step not yet implemented");
}
@When("clicks login button")
public void clicksLoginButton() {
throw new RuntimeException("Step not yet implemented");
}
@Then(“the use should be logged in")
public void theUserShouldBeLoggedIn() {
throw new RuntimeException("Step not yet implemented");
}
}

18. Working Example
A Happy Path Order Capture

19. JUnit Testing using BDD
 Mockito

20. Mockito
 Mockito library enables mocks
creation, verification and stubbing.
 Similar to Jbehave with
given, when, then steps..
 Enables Behaviour testing of java
components i.e
Formhandlers, Managers, Repositories..
etc.
 Mocks all objects a component uses and
verifies if it is using it correctly according
to the behaviour.

21. Mockito Example
public class RepositoryUpdaterTest {
@Mock MutableRepository mockRepository;
@Mock MutableRepositoryItem mockRepsitoryItem;
@Test
public void shouldUpdateRepositoryWithAString() throws Exception {
//given
String valueToBeCreated ="Test";
RepositoyUpdater repositoyUpdater = new RepositoyUpdater();
repositoyUpdater.setSomeRepository(mockRepository);
//when
repositoyUpdater.updateRepositoryWithThisString(valueToBeCreated);
//Then
verify(mockRepository).createItem(valueToBeCreated);
}
}

22. Continuous Integration
A quick feedback

23. What we have
 CI Topology
 Check in build Pipeline
 Release Builds Pipeline
 Check-in best practice

24. The CI

25. Check-in Builds Pipeline

26. Check-in Builds

27. Static Code Analysis

28. Sonar Report

29. Release Build Pipeline

30. Release Builds

31. Deployment Pipeline

32. Automated Database Change
Process
Using DBDeploy

33. Acceptance Tests

34. The Status

35. Check-in Best Practice
 CI monitor close vicinity
 Checkout when CI is green
 Just before checkin see if CI is still green
 If Red then wait until green, find out why it is red
 Do a get when its green
 Build locally again with tests.
 Then Checkin
 Check for CI building your code.
 If Red due to your checkin, fix it ASAP
 When CI is green after your checkin, then relax

36. For more information
 BDD : http://dannorth.net/introducing-bdd/
 Jbehave : http://jbehave.org/
 Mockito :
http://mockito.googlecode.com/svn/tags/latest/j
avadoc/org/mockito/Mockito.html
 Jbehave Code generator :
http:/www.mazataz.com/resources.html

37. Questions?