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.
### 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)