diff options
| author | Thomas Schwinge <thomas@schwinge.name> | 2011-09-29 20:19:15 +0200 |
|---|---|---|
| committer | Thomas Schwinge <thomas@schwinge.name> | 2011-09-29 20:19:15 +0200 |
| commit | b2e4da9e0c71a62f053aa9a8586089d77b24f4e9 (patch) | |
| tree | 3b67d004435f2bcfd7172e0be854880931b79c42 | |
| parent | f1fca083b332711d4befd76fbbf44e6bc39aed28 (diff) | |
patchformatting: Test Suite Enhancements
Based on the emails starting at
id:"87liu2kcq6.fsf@servo.factory.finestructure.net".
| -rw-r--r-- | patchformatting.mdwn | 10 |
1 files changed, 10 insertions, 0 deletions
diff --git a/patchformatting.mdwn b/patchformatting.mdwn index cf5bf81..914371d 100644 --- a/patchformatting.mdwn +++ b/patchformatting.mdwn @@ -41,6 +41,16 @@ Eric S. Raymond has written good [Software Release Practice HOWTO](http://tldp.org/HOWTO/Software-Release-Practice-HOWTO/). Check what he has to say about this issue. +### Test Suite Enhancements + +New features as well as bug fixes should typically come with test suite +enhancements. The test suite changes should be done first (tagged as *expected +to fail*), and the feature implementation or bug fix should come second +(removing the *expected to fail* tag). This way, the test suite specifies the +behavior you're trying to implement, be it a new feature or a bug fix. By +defining beforehand exactly what you expect to happen, everyone can confirm +that your patch achieves what it is meant it to. + ## Prepare patches for e-mail submission If you've made just one commit (containing just one bugfix or new feature) |