File: README.DEVELOPMENT

package info (click to toggle)
jmock2 2.5.1+dfsg-2
  • links: PTS, VCS
  • area: main
  • in suites: wheezy
  • size: 1,296 kB
  • sloc: java: 7,436; xml: 541; sh: 122; makefile: 24; ansic: 9
file content (41 lines) | stat: -rw-r--r-- 1,381 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
Development rules
=================

Here are some rules that we follow when developing jMock:

 * Never check in a class without associated unit tests.

 * Never check a failing unit test into the CVS repository.

 * Acceptance tests may fail. A failing acceptance test indicates
   something that needs to be done: a todo item, feature request or
   bug report, for example. It's ok to check a failing acceptance test
   into the CVS repository.

 * Separate acceptance  and unit tests. Make  it easy to  run only the
   unit tests so that we can check that they pass before committing,
   even when acceptance tests are failing.

 * Resolve and remove all TODO comments before checking in.

 * Avoid the following words in class names and other identifiers:
   Helper, Impl (or a derivative), Manager.

 * And the reverse: don't start interfaces with an I.

 * Follow the Sun: use Sun's coding conventions for Java1.

 * Use the TestDox naming conventions for unit tests.


Architectural Constraints
=========================

* No dependency on any specific test framework.

That means, don't use JUnit Assert.assertBlahBlah to check expectations.
Throw ExpectationError to report a violated expectation.
Throw some kind of RuntimeException to report programming errors in the
use of the framework.  E.g. trying to set up an expectation to return a 
result of the wrong type.