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.
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
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