-
Notifications
You must be signed in to change notification settings - Fork 1
Contributor Guide
Steve Barber edited this page Nov 24, 2013
·
5 revisions
ant clean before you commit. Seriously. Thanks.
- Make sure the tests all do the right thing before you commit, yes, including the database fixture tests. Unfortunately, not all the tests will be green for them to have "succeeded" because we haven't figured out how have an expected failure succeed. (When testing fixtures, you need to make sure that fixtures do the right thing when failing a test.) So you have to look at each failing test to make sure it is appropriately failing. At the moment, the tests that are supposed to fail are:
- DequeueWithTimeout
- ExampleTest
- NotInDequeueTest
- SqlQuery
- UnorderedDequeueCsv
A sample of a "succeeding" test suite run currently looks like this:
Add tests for what you add or change. Do your best to cover the contributed functionality well. Do your best to write tests that are green when they succeed. Document where a failed test is really a success, preferably in the test itself. Use the tests to document your change functionality wherever possible.
When you commit your change to git, write your comment as if it were going to be a release note to the users about your change, because the git log entries are the release notes. Make the comments short and if there is more to say, succinctly refer to where you said more. Please don't commit without a descriptive comment.