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.
Difference between revisions of "Swordfish:ProjectRules:CoDoD"
(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...) |
(Adding definition for Feature Completeness) |
||
| Line 1: | Line 1: | ||
| − | == | + | == 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 | * Code formatting according to the Eclipse build-in formatting rules | ||
* JavaDocs are in place where required (e.g. public methods, constants, etc.) | * JavaDocs are in place where required (e.g. public methods, constants, etc.) | ||
| Line 8: | Line 35: | ||
| − | + | === Unit tests are created/refactored and checked to the subversion repository === | |
* Only created code should be tested. | * Only created code should be tested. | ||
* Tests should concentrate on the code internals and not on the interfaces | * Tests should concentrate on the code internals and not on the interfaces | ||
| Line 27: | Line 54: | ||
| − | + | === Integration tests are created and checked to the subversion repository === | |
* Should minimize scope to subsystem under test | * Should minimize scope to subsystem under test | ||
* Should be portable - should be runnable on developer PC with some setup required | * Should be portable - should be runnable on developer PC with some setup required | ||
| Line 35: | Line 62: | ||
| − | + | === To be done later === | |
* System tests are created and checked to the subversion repository. | * System tests are created and checked to the subversion repository. | ||
* Peer code review | * Peer code review | ||
* User acceptance tests | * User acceptance tests | ||
* Continuous integration build is successful with the changes. | * Continuous integration build is successful with the changes. | ||
Revision as of 14:48, 21 February 2009
Contents
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
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.