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
42
43
44
45
46
47
48
|
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 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 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.
* 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.
Release
=======
mvn versions:set -DoldVersion=2.8.1-SNAPSHOT -DnewVersion=2.8.1 -DgroupId=org.jmock
find . -name pom.xml.versionsBackup -exec rm {} \;
eval $(gpg-agent --daemon --no-grab --write-env-file $HOME/.gpg-agent-info)
export GPG_AGENT_INFO
export GPG_TTY=$(tty)
mvn clean deploy -P release --settings settings.xml -Dgpg.keyname=XXXXXXXX
|
