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