Difference between revisions of "Swordfish:ProjectRules:CoDoD"

Revision as of 15:51, 21 February 2009

Feature Completeness

Installation

• The Function is available as an Eclipse Feature (either as new Bundle or included into an Existing Feature, based on the Eclipse Feature Bundle definition)
• The Feature is available on the Update Site of Eclipse
• In case the installation is different from Standard Eclipse Features or Plugins documentation of the necessary steps is required.

Deloyment

Deployment of Swordfish components (OSGi Bundles) itself is a feature of swordfish. As soon as this is working the following requirement becomes valid for feature completeness:

• The Feature can be deployed using the Swordfish Deployment Tool.
• OSGi Bundles already deployed in the same Target are not negatively affected by the additional deployed function.

Start/Run/Control

• It is required that each new Function/Feature can be controlled by the user with usual eclipse methods. Control means: start, run, activate, stopp. This can be fulfilled by providing a new control function or integrating it, by extending an existing control function.
• The control options are documented.

Documentation

• Initial Documentation shall be provided on the Swordfish Documentation Wiki
• All Examples, Control functions and Tools shall be documented as Eclipse Help.

Examples

• For each Function which can be directly accessed by a user an example shall be provided.
• The example shall have a control function and shall be documented in Eclipse Help.
• Each function which is relevant for application developers shall be covered in a tutorial, i.e the programmatic interface.
• Cheat sheets should be considered where useful.

Developer Agreement: 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

Continuous integration build is successful

• It is very important that after each checkin to the trunk developer waits till the notification from continuos integration server.
• We will try our best to keep the build times short that you wold be able to get a fast feedback.
• Please avoid "checkin and go home/on the weekend/on vacation" anti-pattern.

To be done later

• System tests are created and checked to the subversion repository.
• Peer code review
• User acceptance tests