java development best practices
TRANSCRIPT
Java Development Best PracticesSimon Brown, Senior Consultant
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
Contents
Presentation Objectives
Automated unit testing
Continuous integration
Project blogs
Other best practices
Summary
Ref: www.evolution.net Page 4
Presentation Objectives
Provide an overview of the following Cormorant MFEdevelopment practices, how to implement them and how theyprovide real benefit
– Automated unit testing– Continuous integration– Project blogs
To discuss other best practices that we have used in the pastand/or should be using in the future
Ref: www.evolution.net Page 5
A quote from a blog entry…
On August 4 we had a session on software engineering. The aim of the sessionwas to share knowledge and experience about the way we develop software andto discuss the importance of doing it a certain way. After the break we had aworkshop that briefly touched the different parts of the software developmentprocess.
The quiz on current real-life practices raised a lot of discussion. While we allrecognize the importance of source control, automation of manual tasks, testing,documentation and proper incident management many of us fail in a properimplementation of these practices.
AMIS Technology Corner : On Software Engineeringhttp://technology.amis.nl/blog/index.php?p=695
Ref: www.evolution.net Page 6
Contents
Presentation Objectives
Automated unit testing
Continuous integration
Project blogs
Other best practices
Summary
Ref: www.evolution.net Page 7
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 8
Test classReal class
Automated unit testing
method1
method2
methodN
testMethod1
testMethod2
testMethodN
Ref: www.evolution.net Page 9
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 10
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 11
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 12
Adoption of automated unit testing
Don’t mandate 100% unit test coverage - it’s too hard and tooexpensiveDo use a code coverage tool (more on this later)Do add tests when you see they don’t already existDo write tests to prove bugsDo run your tests frequentlyDo make sure the tests execute quicklyDon’t let the tests become out of dateDon’t throw them away when they stop passing - fix them!Do treat them as an important deliverableDo include them in code reviews
Ref: www.evolution.net Page 13
Contents
Presentation Objectives
Automated unit testing
Continuous integration
Project blogs
Other best practices
Summary
Ref: www.evolution.net Page 14
Developer PC
Server
Cormorant development environment
Check-out code
Commit codeSource code
Control(Subversion)
WeblogContinuousIntegration
Server
Developer PC
Developer PC
Developer PC
Ref: www.evolution.net Page 15
Manual build process
Manual builds performed using Eclipse and command linetoolsScripted 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 16
Scheduled, scripted builds
Scheduled, scripted builds performed by CruiseControl andAnt
– 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 17
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 slippageForces 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 18
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, etcAlso look at other continuous integration servers such asAnthill
Ref: www.evolution.net Page 19
Contents
Presentation Objectives
Automated unit testing
Continuous integration
Project blogs
Other best practices
Summary
Ref: www.evolution.net Page 20
What is a blog?
Blog, short for weblog : a web-based log or diaryLess formal than static project websites or wikisInformation stored on a temporal basisUseful for recording snippets of information as they are encountered
– Project information, development tips, environment gotchas, logininformation, links to documents, documents, instructions, guidelines,links to external resources, status reports, etc
– Also build information and test resultsAn alternative to sending out short e-mail memosCan be searched, archived and exportedWeb-based access means easy distribution of informationLow maintenance
Ref: www.evolution.net Page 21
Project blogsRather than have asingle blog for theproject, there are two:
• Team blog (used forproject information).
• Build blog (used forbuild reports).
Ref: www.evolution.net Page 22
Team blogThis is the project teamblog and is used forsharing informationabout any aspect of theproject.
• All Evolution teammembers can contributeto this and have accessto do so.
• Anybody in theextended team can leavecomments, but only theEvolution team can addcontent.
• Instead of writing e-mail memos, content ispublished to the blog anda link sent to the team.
• Since blog content isHTML, it’s easy to embedimages and link toproject artefacts.
• With an RSS readerinstalled on eachdesktop, the team isautomatically notified ofnew content.
Ref: www.evolution.net Page 23
Build blogThis is the project buildblog and is used topublish build summaries.
• CruiseControl performsa checkout/build eachhour and publishes theresults.
• With an RSS reader, theteam is automaticallynotified after builds occur.
• Anybody can leavecomments, but this bloghas been configured sothat only CruiseControlcan publish content.
Ref: www.evolution.net Page 24
Summary pageThis is the summarypage for both blogs,showing the last threeentries that have beenposted to each.
• Navigation is the samefor the other blogs andclicking on links in thecalendar shows allcontent for that period.
• The Today link (top)shows all contentpublished today acrossboth blogs.
• The RSS/RDF/Atomlinks (top) allow anewsreader application tosubscribe to both blogsvia a single feed.
Ref: www.evolution.net Page 25
Blog is green,build is clean!Through somecustomization, the blog isused as a form ofextreme feedback device:
• Green means the lastbuild was successful.
• Red means the lastbuild failed.
• The main page of theblog is set toautomatically refreshevery few minutes.
Ref: www.evolution.net Page 26
Blog is green,build is clean!Through somecustomization, the blog isused as a form ofextreme feedback device:
• Green means the lastbuild was successful.
• Red means the lastbuild failed.
• The main page of theblog is set toautomatically refreshevery few minutes.
Ref: www.evolution.net Page 27
Contents
Presentation Objectives
Automated unit testing
Continuous integration
Project blogs
Other best practices
Summary
Ref: www.evolution.net Page 28
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 29
Clover in IntelliJ IDEA
Ref: www.evolution.net Page 30
Clover HTML reports
Ref: www.evolution.net Page 31
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 32
Contents
Presentation Objectives
Automated unit testing
Continuous integration
Project blogs
Other best practices
Summary
Ref: www.evolution.net Page 33
Automated unit testing summary
Easy to setupEasy to get to grips withIncreases confidence that a solution/fixes/changes workEnsures a certain level of continuous quality assurance
Ref: www.evolution.net Page 34
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 35
Continuous integration summary
Easy to setupDoesn’t require much processing powerDoesn’t require a dedicated boxDoesn’t require expensive software
– Open source software used in MFE development environmentProvides early warning signs to integration problems
– Code not compiling– Unit tests failing
Helps developers integrate more smoothlyEnsures a certain level of continuous quality assurance
Ref: www.evolution.net Page 36
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 37
Project blog summary
Also don’t require much processing power, a dedicated boxor expensive softwareProvides a way to easily publish information to the projectteam
– Can be searched, archived and exported– Easily distributed to extended project team
Team members can subscribe to the information they want toreceiveA useful feedback mechanism when combined withcontinuous integration
Ref: www.evolution.net Page 38
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 39