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

Difference between revisions of "Swordfish:ProjectRules:CoDoD"

(Adding definition for Feature Completeness)
(Unit tests are created/refactored and checked to the subversion repository)
 
(3 intermediate revisions by 2 users not shown)
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==
 
==Developer Agreement: Common definition of "Done" for Swordfish project==
  
Line 51: Line 24:
 
** Network, servers
 
** Network, servers
 
* Tests should have a short run time (<1 second per test)
 
* Tests should have a short run time (<1 second per test)
* Unit tests should cover 90% of the production code
+
* Unit tests should cover 70% of the production code
 
+
  
 
=== Integration tests are created and checked to the subversion repository ===
 
=== Integration tests are created and checked to the subversion repository ===
Line 61: Line 33:
 
* Mocks should be not stubs - http://martinfowler.com/articles/mocksArentStubs.html
 
* 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 immediately go home/on the weekend/on vacation/around the world in only 90 days" anti-pattern.
  
 
=== To be done later ===
 
=== To be done later ===
Line 66: Line 43:
 
* Peer code review
 
* Peer code review
 
* User acceptance tests
 
* User acceptance tests
* Continuous integration build is successful with the changes.
+
 
 +
Related Topic: <br/>
 +
See also the default [[Swordfish_Documentation:_Feature_Completenes_Definition | feature completeness criteria]] in the Swordfish Documentation Wiki.

Latest revision as of 09:04, 3 April 2009

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 70% 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 immediately go home/on the weekend/on vacation/around the world in only 90 days" anti-pattern.

To be done later

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

Related Topic:
See also the default feature completeness criteria in the Swordfish Documentation Wiki.

Back to the top