Java Development Best Practices

Simon Brown, Senior Consultant

Contents
Presentation Objectives

Automated unit testing

Continuous integration

Project blogs

Other best practices

Summary

Ref: www.evolution.net Page 2

Contents
Presentation Objectives

Automated unit testing

Continuous integration

Project blogs

Other best practices

Summary

Ref: www.evolution.net Page 3

Presentation Objectives
Provide an overview of the following Cormorant MFE
development practices, how to implement them and how they
provide real benefit
– Automated unit testing
– Continuous integration
– Project blogs

To discuss other best practices that we have used in the past

and/or should be using in the future

Ref: www.evolution.net Page 4

 A quote from a blog entry…

On August 4 we had a session on software engineering. The aim of the session

was to share knowledge and experience about the way we develop software and
to discuss the importance of doing it a certain way. After the break we had a
workshop that briefly touched the different parts of the software development
process.

The quiz on current real-life practices raised a lot of discussion. While we all
recognize the importance of source control, automation of manual tasks, testing,
documentation and proper incident management many of us fail in a proper
implementation of these practices.

AMIS Technology Corner : On Software Engineering

http://technology.amis.nl/blog/index.php?p=695

Ref: www.evolution.net Page 5

Contents
Presentation Objectives

Automated unit testing

Continuous integration

Project blogs

Other best practices

Summary

Ref: www.evolution.net Page 6

Automated unit testing
Automated unit testing now an established technique
– You write some code
– Then you write more code to test it
Many frameworks exist for automated unit testing with Java
– Most popular is Junit 3.8.x
– Others include TestNG and JUnit 4.0

Ref: www.evolution.net Page 7

Automated unit testing

method1 testMethod1

method2 testMethod2

methodN testMethodN

Real class Test class

Ref: www.evolution.net Page 8

Automated unit testing
Yes…
– More code needs to be written
– Estimates will increase
– It’s a new way of working
– It feels weird, perhaps pointless initially
But…
– Automated unit testing is very powerful
– Lets you regression test code for free!
– Helps you write cleaner code
– Provides a good milestone for completion
– Provides confidence when changing, fixing or refactoring code
– If you can write code, you can write a unit test!

Ref: www.evolution.net Page 9

Adoption of automated unit testing
New code
– Write tests for new code

Existing code that needs to be modified…

– Look at the unit tests
– If tests exist, they will help ensure you don’t break anything
through unknown side effects
– If tests don’t exist, write some to cover the area of the code you
are changing
– No need to retrofit the entire code base with unit tests at once
• Too expensive!
• Take an iterative approach

Ref: www.evolution.net Page 10

Adoption of automated unit testing
A defect is raised…
– Look at the unit tests
– Write a unit test to prove the bug - make sure its reproducible
– Fix the bug
– The new test will pass
– Check-in the fix and new test
– Chances of reoccurrence are greatly reduced

Ref: www.evolution.net Page 11

Adoption of automated unit testing
Don’t mandate 100% unit test coverage - it’s too hard and too
expensive
Do use a code coverage tool (more on this later)
Do add tests when you see they don’t already exist
Do write tests to prove bugs
Do run your tests frequently
Do make sure the tests execute quickly
Don’t let the tests become out of date
Don’t throw them away when they stop passing - fix them!
Do treat them as an important deliverable
Do include them in code reviews

Ref: www.evolution.net Page 12

Contents
Presentation Objectives

Automated unit testing

Continuous integration

Project blogs

Other best practices

Summary

Ref: www.evolution.net Page 13

Cormorant development environment

Developer PC

Developer PC
Commit code
Source code
Developer PC Control
(Subversion)

Continuous
Developer PC Weblog Integration
Server
Check-out code

Server

Ref: www.evolution.net Page 14

Manual build process
Manual builds performed using Eclipse and command line
tools
Scripted builds performed using Ant and existing script
– Compile Java code
– Build EAR file
– Generate distribution for release to system test

Ref: www.evolution.net Page 15

Scheduled, scripted builds
Scheduled, scripted builds performed by CruiseControl and
Ant
– Build scheduled every hour/30 minutes
– Clean copy of code checked out from Subversion
– Compile, build EAR file and run unit (JUnit) tests
– Build results published to CruiseControl web application
– Build results also published to build blog

CruiseControl was our sixth team member!

Ref: www.evolution.net Page 16

Benefits of scheduled, scripted builds
Forces more frequent, iterative integration rather than big-
bang approach
– Forces compilation of clean codebase
– Finds compilation problems where developers have not updated
their local copy of code before checking in changes
– Frequent (continuous) integration is easier and quicker to
perform, reducing risk of slippage
Forces execution of unit tests
– Automatically runs all unit tests whenever the codebase changes
– Finds problems when developers have not run tests before
checking in changes
– Provides a level of continuous quality assurance

Ref: www.evolution.net Page 17

Setting up continuous integration
CruiseControl installed on a PC (can be developer PC)
– Configured to look at the repository every hour for changes
– If changes are found, code is checked out and build executed
CruiseControl provides native integration with CVS,
Subversion, ClearCase, etc
Also look at other continuous integration servers such as
Anthill

Ref: www.evolution.net Page 18

Contents
Presentation Objectives

Automated unit testing

Continuous integration

Project blogs

Other best practices

Summary

Ref: www.evolution.net Page 19

What is a blog?
Blog, short for weblog : a web-based log or diary
Less formal than static project websites or wikis
Information stored on a temporal basis
Useful for recording snippets of information as they are encountered
– Project information, development tips, environment gotchas, login
information, links to documents, documents, instructions, guidelines,
links to external resources, status reports, etc
– Also build information and test results
An alternative to sending out short e-mail memos
Can be searched, archived and exported
Web-based access means easy distribution of information
Low maintenance

Ref: www.evolution.net Page 20

 Project blogs
R athe r than have a
single blog for the
proje ct, the re are two:

• Te am blog (use d for

proje ct inform ation).

• Build blog (use d for

build re ports).

Ref: www.evolution.net Page 21

 Team blog
This is the proje ct te am
blog and is use d for
sharing inform ation
about any aspe ct of the
proje ct.

• All Evolution te am
m e m be rs can contribute
to this and have acce ss
to do so.

• Anybody in the
e x te nde d te am can le ave
com m e nts, but only the
Evolution te am can add
conte nt.

• Inste ad of writing e -
m ail m e m os, conte nt is
publishe d to the blog and
a link se nt to the te am .

• Since blog conte nt is

HTML, it’s e asy to e m be d
im age s and link to
proje ct arte facts.

• W ith an R SS re ade r
installe d on e ach
de sk top, the te am is
autom atically notifie d of
ne w conte nt.

Ref: www.evolution.net Page 22

 Build blog
This is the proje ct build
blog and is use d to
publish build sum m arie s.

• C ruise C ontrol pe rform s

a che ck out/build e ach
hour and publishe s the
re sults.

• W ith an R SS re ade r, the

te am is autom atically
notifie d afte r builds occur.

• Anybody can le ave

com m e nts, but this blog
has be e n configure d so
that only C ruise C ontrol
can publish conte nt.

Ref: www.evolution.net Page 23

 Summary page
This is the sum m ary
page for both blogs,
showing the last thre e
e ntrie s that have be e n
poste d to e ach.

• Navigation is the sam e

for the othe r blogs and
click ing on link s in the
cale ndar shows all
conte nt for that pe riod.

• The Today link (top)

shows all conte nt
publishe d today across
both blogs.

• The R SS/R DF/Atom

link s (top) allow a
ne wsre ade r application to
subscribe to both blogs
via a single fe e d.

Ref: www.evolution.net Page 24

 Blog is green,
build is clean!
Through som e
custom ization, the blog is
use d as a form of
e x tre m e fe e dback de vice :

• Gre e n m e ans the last

build was succe ssful.

• R e d m e ans the last

build faile d.

• The m ain page of the

blog is se t to
autom atically re fre sh
e ve ry fe w m inute s.

Ref: www.evolution.net Page 25

 Blog is green,
build is clean!
Through som e
custom ization, the blog is
use d as a form of
e x tre m e fe e dback de vice :

• Gre e n m e ans the last

build was succe ssful.

• R e d m e ans the last

build faile d.

• The m ain page of the

blog is se t to
autom atically re fre sh
e ve ry fe w m inute s.

Ref: www.evolution.net Page 26

Contents
Presentation Objectives

Automated unit testing

Continuous integration

Project blogs

Other best practices

Summary

Ref: www.evolution.net Page 27

Roundtable discussion about other best practices
Code coverage
– Clover, jcoverage, etc
Automatic conformance to standards
– Checkstyle, PMD, etc
Tracking metrics over time
– QALab
Automated acceptance testing
– HttpUnit, Canoo WebTest, etc

Demos of Clover and Canoo WebTest

Ref: www.evolution.net Page 28

Clover in IntelliJ IDEA

Ref: www.evolution.net Page 29

Clover HTML reports

Ref: www.evolution.net Page 30

Canoo WebTest script
<!DOCTYPE project SYSTEM "../WebTest.dtd"[
<!ENTITY definition SYSTEM "../includes/definition.xml">
<!ENTITY config SYSTEM "../includes/config.xml">
]>
<project name="test" basedir="." default="main">

&definition;

<target name="main">
<webtest name="login">
&config;
<steps>
<invoke description="Request secured resource" url="/login.secureaction" />
<verifyInputField name="j_username" value="" />
<verifyInputField name="j_password" value="" />

<setInputField name="j_username" value="simon" />

<clickButton label="Login" />

<verifyText description="Check user logged in" text="Logged in as simon" />

</steps>
</webtest>
</target>
</project>

Ref: www.evolution.net Page 31

Contents
Presentation Objectives

Automated unit testing

Continuous integration

Project blogs

Other best practices

Summary

Ref: www.evolution.net Page 32

Automated unit testing summary
Easy to setup
Easy to get to grips with
Increases confidence that a solution/fixes/changes work
Ensures a certain level of continuous quality assurance

Ref: www.evolution.net Page 33

Automated unit testing software
JUnit
– Open source
– Easy to install and configure
– Integrates with Ant for scripted builds
– Integrated with Eclipse allowing tests to be written and run very
quickly
– http://www.junit.org

Ref: www.evolution.net Page 34

Continuous integration summary
Easy to setup
Doesn’t require much processing power
Doesn’t require a dedicated box
Doesn’t require expensive software
– Open source software used in MFE development environment
Provides early warning signs to integration problems
– Code not compiling
– Unit tests failing
Helps developers integrate more smoothly
Ensures a certain level of continuous quality assurance

Ref: www.evolution.net Page 35

Continuous integration software
CruiseControl
– Open source
– Easy to install and configure
– Native integration with all leading/standard source code control
interfaces
– Can publish build reports via e-mail, XML, HTML, blogs, etc
– Only performs builds when code in repository has changed
– http://cruisecontrol.sourceforge.net

Ref: www.evolution.net Page 36

Project blog summary
Also don’t require much processing power, a dedicated box
or expensive software
Provides a way to easily publish information to the project
team
– Can be searched, archived and exported
– Easily distributed to extended project team
Team members can subscribe to the information they want to
receive
A useful feedback mechanism when combined with
continuous integration

Ref: www.evolution.net Page 37

Project blog software
Pebble
– Open source
– Easy to install and configure
– Runs on most J2EE web/application servers (e.g. Tomcat)
– Flexible security roles
– Integrates with enterprise authentication mechanisms
– Supports standard interfaces such as Atom/RSS newsfeed
formats and XML-RPC
– http://pebble.sourceforge.net

Ref: www.evolution.net Page 38

 Questions?
[email protected]

Ref: www.evolution.net Page 39