Best Practices SIG Update

1
Best Practices SIG Update

• Moses Hohman, Northwestern University
• Jim Kadin, Jackson Laboratory
• February 2, 2006

2
Outline

• Recap of BP Review Process (Jim)
• Summary of BP/SOP in the pipeline (Jim)
• WS introduction to two BPs under review (Moses)
• Unit Testing with JUnit, and
• Automating Builds with Ant
• Architecture BP Survey (Moses)

3
(No Transcript)
4
BPs/SOPs in the pipeline
Presented, and need small review groups

• Presented to VCDE (2/26)
• CDE Standards Reviews (Brian)

• Presented to WS today
• Unit Testing with JUnit (Moses)
• Automating Builds with Ant (Moses)

5
BPs/SOPs in the pipeline

• Drafts in Progress
• SDK Users Guide looking for feedback (Denise
  Warzell)
• Semantic Connector (Sal Mungal)
• Silver Level Compatibility Reviews (Brian)
• Looking for an Author
• Software Versioning/Numbering

6
BP Infrastructure Under Development

• BP GForge site
• http//gforge.nci.nih.gov/projects/archvcdebpsig/
• Links to Wiki, based on MediaWiki, hosted at
  Northwestern
• BP/SOP templates
• Current versions available in the Files section
  at the GForge website
• Still evolving
• Hand off to Training WG details under discussion

7
(No Transcript)
8
Unit Testing with JUnit

• Identified high priority by NCICB and BAH
• The document is currently a Guideline, not a
  Requirement
• Leverages existing books, articles, etc.
• Provides
• standards for organizing unit test source code
• standards for running unit tests
• common dangers and misconceptions
• points to remember
• examples

9
Scope

• Addresses two skills
• Learning to write effective automated tests in
  general
• Learning to use JUnit to perform such testing
• Only addresses tests that are
• Automated
• At the unit level (not system tests, load tests,
  acceptance tests, etc.)

10
References

• Caveat I did not learn automated unit testing
  from books
• Pragmatic Programmers Pragmatic Unit Testing
  with JUnit
• Rainsberger and Stirling JUnit recipes
• Kent Beck Test Driven Development
• www.junit.org
• Others people have found useful?

11
Key Benefits

• Faster Development Cycles
• Less Manual Testing
• Fewer Bugs
• Improved Software Design

12
Guidelines

• Starting point read a book
• Common conventions
• Organizing source code
• Running unit tests
• Common dangers
• Points to remember
• Examples

13
Common Dangers

• Where to start with a body of untested code
• Database dependent tests
• Slowly running tests
• Complex (LOC, complex logic) tests
• Writing tests after application code is complete

14
Points to Remember

• Avoid coupling test cases
• Keep test methods short
• The tests test the code, and the code tests the
  tests.
• Automated tests are here to help you, not hinder
  you make sure theyre doing that
• Measure test code coverage http//emma.sourceforg
  e.net

15
Examples

• Testing and exceptions
• setUp() and tearDown()
• Testing lists/sets/arrays for equality
• Removing dependencies stubs/mocks
• Resolving dependencies using the classpath,
  dependency injection

16
Automating Builds with Ant

• Another high priority identified by NCICB and BAH
• Also a Guideline rather than a Requirement
• Defines key benefits
• Discusses points to remember and provides examples

17
Automating Builds with Ant

• Ant (http//ant.apache.org) is an automated build
  tool, like make or Rake
• Dependency based programming model
• Building software becomes a turnkey process,
  leading to
• Increased consistency in both build process and
  artifacts
• Fewer headaches

18
References

• Caveat again, I did not learn Ant from books.
• http//ant.apache.org/manual
• Others?

19
Points to remember

• Using ltpropertygts
• Built-ins, setting using build.xml, properties
  file, environment
• Using dependencies instead of ltantcallgt
• Paths
• Conditional logic nearly absent, what to do?
• Using custom tasks (classpath issues), scripting
• Documenting unusual build targets
• Running unit tests

20
Examples

• Standard build file compile, test, jar
• Using properties files
• Using custom tasks

21
Survey

• We need to know what you want from us.
• Weve listed best practices and SOPs that have
  already been suggested. Please rank these in
  order of importance (no ties). You can also
  include your own suggestions in the rankings.
• We also ask about the value of sharing practices
  that are not necessarily best, and how we might
  do this as a community