Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Swordfish:ProjectRules:CoDoD

Revision as of 11:51, 12 February 2009 by Juergen.kindler.sopera.de (Talk | contribs) (New page: ==Common definition of "Done" for Swordfish project== '''Code is created/refactored and checked to the subversion repository''' * Code formatting according to the Eclipse build-in formatt...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Common definition of "Done" for Swordfish project

Code is created/refactored and checked to the subversion repository

  • Code formatting according to the Eclipse build-in formatting rules
  • JavaDocs are in place where required (e.g. public methods, constants, etc.)
  • Copyright headers are in place (AP: create Eclipse template and check to repository)
  • Cyclomatic complexity should be <= 10 at most 15


Unit tests are created/refactored and checked to the subversion repository

  • Only created code should be tested.
  • Tests should concentrate on the code internals and not on the interfaces
  • Treat test code as production code (e.g. refactoring, modularity, etc).
  • Minimize setup/teardown parts of unit tests
  • No external setup required to run tests. Tests should be runnable in:
    • Eclipse
    • Command line (mvn)
    • Continuous integration environment
  • Tests should be independent of:
    • File system
    • Operating system
    • Timing
    • Threading
    • Network, servers
  • Tests should have a short run time (<1 second per test)
  • Unit tests should cover 90% of the production code


Integration tests are created and checked to the subversion repository

  • Should minimize scope to subsystem under test
  • Should be portable - should be runnable on developer PC with some setup required
  • Required setup should be reasonably simple
  • Mocks should be shared, before creating a new one please have a look on existing
  • Mocks should be not stubs - http://martinfowler.com/articles/mocksArentStubs.html


To be done later

  • System tests are created and checked to the subversion repository.
  • Peer code review
  • User acceptance tests
  • Continuous integration build is successful with the changes.

Back to the top