aboutsummaryrefslogtreecommitdiffhomepage
path: root/docs/CONTRIBUTING
diff options
context:
space:
mode:
authorGravatar uranther <jwheaton@purdue.edu>2009-07-15 17:27:19 -0400
committerGravatar uranther <jwheaton@purdue.edu>2009-07-15 17:27:19 -0400
commitf9e93ba19d4d166d81d53e7b4bc222ef8d4e9632 (patch)
tree4b595bd870f34603f100855e83da31da30b9e353 /docs/CONTRIBUTING
parent3a18de9cb89ba7de3354dda7d9dd53f990c34eac (diff)
Changed my instructions for unit tests in docs/CONTRIBUTING
Diffstat (limited to 'docs/CONTRIBUTING')
-rw-r--r--docs/CONTRIBUTING6
1 files changed, 5 insertions, 1 deletions
diff --git a/docs/CONTRIBUTING b/docs/CONTRIBUTING
index 9032b42..5a88330 100644
--- a/docs/CONTRIBUTING
+++ b/docs/CONTRIBUTING
@@ -66,7 +66,6 @@ This is a relatively easy, solid and transparent way to handle all requests in o
we know for bigger changes this is not always feasible. Just try to keep the merges about bigger "clean changesets".
* Your code should not introduce any compile warnings or errors. And also,
no regressions but that's harder to check.
-* Unit tests should be written to verify bug fixes and new functionality.
That said, you can always ask us to check on your stuff or ask for advice.
@@ -91,6 +90,11 @@ is, please supply:
### Memory leak checking
valgrind --tool=memcheck --leak-check=full ./uzbl
+### Writing unit tests
+If you can, write a unit test for a bugfix or new functionality. Add relevant unit
+tests to existing .c files in tests/. Others should be made in new source files with
+corresponding changes to the tests/Makefile.
+
### Debugging / backtraces
* compile with -ggdb (enabled by default on experimental tree)