X-Git-Url: https://git.cworth.org/git?a=blobdiff_plain;f=patchformatting.mdwn;h=914371d4da071d916340c945304a26f02e06021c;hb=b2e4da9e0c71a62f053aa9a8586089d77b24f4e9;hp=cf5bf813c082337c0e3f2799b3f12f1588ef184a;hpb=889266d3dfcd3f478978cf136a94f3448696999a;p=notmuch-wiki

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)