This document discusses BSG's approach to agile software development. It covers their use of agile methodologies like Scrum, test-driven development, behavior-driven development, and pair programming. It also describes their testing strategy, which uses a hybrid of BDD and TDD with a domain specific language. Tests are written at multiple levels, from acceptance to unit, and are run locally and through continuous integration with Jenkins.

1. Copyright BSG
BSG Grad Share 2014
Computer Science

2. Plan of Action
• Software Development at BSG
• What is Agile?
• Internal vs. External Quality
• Test Driven Development
(TDD)
• Behaviour Driven Development
(BDD)
• Ping Pong Pairing
• Our Testing Strategy (TDD /
BDD Hybrid)
• Demo

3. Software Development at BSG

4. • Agile / Lean Development Methodology (JIRA Greenhopper)
• Architecture and Frameworks used Depend on the Project
 Conventional JSPs and Javascript libraries
 Google Web Toolkit (as used to write Google Wave)
 Tomcat (servlet container) or full application server
 JPA, Hibernate, Hibernate Search, Lucene
• Our Developers use Windows, Linux (Ubuntu) and Mac
• Development Tools
 IntelliJ IDEA or Eclipse IDE
 ANT for build scripts
 Junit, Hamcrest, Jmock and Jbehave for automated testing
 Jenkins for continuous integration
 Github for version control
 Team members are active contributors on global forums, such as
 A choice is made for each project
• Database is usually MySQL or client's choice (we have used Oracle quite often, for example)
Java Development at BSG

5. What is Agile?
• The highest priority of Agile is to satisfy the customer through early and
continuous delivery of valuable software
– Working software is the primary measure of progress of a project
• Common traits amongst agile methodologies include:
– Frequent product releases
– High levels of real‐time collaboration within the project team and with
customers
– Reduced time intensive documentation
– Regular, recurring assessments of value and risk to allow for change
The Agile Manifesto values:
 Individuals and interactions over processes
and tools
 Working software over comprehensive
documentation
 Customer collaboration over contract
negotiation
 Responding to change over following a plan

6. What makes a
code base agile?
• Properties:
 Lean (least quantity of code to get the job done)
 Well designed (modularised, layered)
 Tested (comprehensive testing strategy)
• Advantages:
 Easy to change without introducing regression issues/bugs
 Easy to maintain (localisation of issues through tests)
 Easy to understand (code = documentation, tests = specification)

7. • Internal quality determines your ability to
move forward on a project
• It is about “building software in the
right way” which is achieved through
white box testing (e.g. unit tests)
• Internal quality = all the properties of the
software as seen by the developers that
are desirable in order to facilitate the
process of creating a good product:
concision: code does not suffer from
duplication
cohesion: each module / class / routine does
one thing and does it well
low coupling: minimal interdependencies
and interrelation between objects
simplicity
generality: the problem domain bounds are
known and stated
clarity: the code enjoys a good auto
documentation level
• External Quality determines the fulfilment
of stakeholder requirements
• It is about “building the right software”
which is achieved through black box
testing (e.g. acceptance tests)
• External quality = all the properties of the
software as a product that users can
experience and enjoy:
conformity to their expectations (and
evolution thereof)
reliability
accuracy
ease of use and comfort (including response
delay)
robustness (or adaptability to some
unforeseen condition of use)
openness (or adaptability to future
extensions or evolutions)
Internal vs.
External Quality

8. Test Driven
Development
• Test-driven development (TDD) is a software development process that relies on the
repetition of a very short development cycle:
 First the developer writes an (initially failing) automated test case that defines a desired
improvement or new function
 then produces the minimum amount of code to pass that test
 and finally refactors the new code to acceptable standards
• Advantages:
 Reduced need to use debugger
 Test driven design (design for testability, “listen to the tests”)
 Incremental
 Faster
 Encourages modularisation and decoupling
 All paths through the code are tested

9. Behaviour Driven Development
• Behaviour-driven development is an
“outside-in” methodology
• It starts at the outside by identifying
business outcomes, and then drills down
into the feature set that will achieve those
outcomes
• Each feature is captured as a “story”,
which defines the scope of the feature
along with its acceptance criteria
• Ubiquitous domain language
• Non-technical / analytical techniques as
well, e.g. feature injection
• Advantages:
Better commitment and buy-in
Right focus
Evolutionary design
Breaking the knowledge silos in
distributed team
Greater ROI
Predictability & confidence

10. • Pair programming is an agile
software development technique
in which two programmers work
together at one workstation
One, the driver, writes code while the
other, the observer or navigator, reviews
each line of code as it is typed in
The two programmers switch roles
frequently
• Ping Pong Pairing (P3) combines
the concepts of TDD and Pair
programming, therefore mitigating
some of pitfalls while realising the
benefits of both
Better engagement from developers
Complete code coverage
Concision, least quantity of code to
get the job done
Reduced corner cutting
Ping Pong Pair
Programming

11. Our Testing
Strategy
A hybrid of BDD and TDD. We use a
combination of state and behaviour
verification.
Language through all tests uses the
same Domain Specific Language
(DSL).
Name tests in an intent revealing
way i.e. test<Method and fixture to
test>_should<Expected result>.

12. What tests do
we write?
• Acceptance tests
• Integration tests
 Query smoke tests
 Query semantics tests
 Round-trip tests
• Unit tests
 Presenter tests
 Service logic tests
 RPC service tests
• Regression tests

13. A Layered
Architecture
• Presentation layer
 MVP to allow for testing this layer
• Service layer
 Mock out lower layers
• Persistence layer
 Interact with the DB)

14. Model View Presenter (MVP)
• A design pattern which facilitates unit testing:
 The model contains the data to be handled by the
presenter and displayed in the view.
 The view simply displays data passed to it from the
presenter, and routes events from the user back to
the presenter.
 The presenter fetches data (the model), performs the
required logic with that data, and passes it to the view
to be displayed.

15. Mocking
• We use JMock
 Behaviour verification
 Fake dependencies
 Return expected values without touching layers below
• Some other popular mocking frameworks include:
 Mockito
 EasyMock

16. Helpers
Builders - construct and
persist domain objects to be
used in tests.
Matchers - to make
assertions and compare
the state of objects.

17. • Developers run tests locally before
pushing changes
• Our Continuous Integration (CI)
server runs the tests as well
• We use Jenkins CI
• A build is triggered when code is
pushed to GitHub
• Jenkins compiles the code and
runs all tests
• If any tests fail a notification email
is sent to the team
Running Tests

18. Testing and Code
Coverage Demo

19. References
• http://agilemanifesto.org/
• http://c2.com/cgi/wiki?InternalAndExternalQuality
• http://meekrosoft.wordpress.com/2010/10/31/internal-and-external-software-quality
• http://en.wikipedia.org/wiki/Test-driven_development
• http://en.wikipedia.org/wiki/Behavior_Driven_Development
• http://dannorth.net/
• http://blogs.agilefaqs.com/2012/11/11/benefits-of-behavior-driven-development-bdd/
• http://en.wikipedia.org/wiki/Pair_programming
• http://behave.readthedocs.org/en/latest/philosophy.html

20. Social media - keep in touch
#2014GradShare #AgileDev