Reputation: 675
For a small development team (6 developers) I set up Gerrit and Jenkins to allow for code review and CI. The integration between both is working fine, with Jenkins compiling and testing the code.
I'm however unable to decide how to handle failing failing tests. Currently if a test fails then the build is considered as failed as well. How would one handle that in the case of changed functionality causing a test to fail? Or when tests are improved and find broken code? Would one always fix the broken code as well, and squash the test changed and the fix into a single commit?
Upvotes: 0
Views: 1210
Reputation: 1876
http://gerrit-documentation.googlecode.com/svn/Documentation/2.6/config-labels.html
You can add an additional topic for testing, so build verification is +1 testing -1, so dividing it in categories, this requires some configuration of the jenkins jobs as the testjobs have to report back in a different manner that the build verification jobs.
But anyway it does the for me.
Upvotes: 1
Reputation: 5532
This is a great question, and it comes down to your development methodologies. I prefer to keep commits as small and compact as possible, so I would want to split up the test changes and code fixes.
You could upload the code fixes first, and not upload your test changes until the code fixes are merged. But having the test changes available is helpful for reviewers to understand why the code fixes are necessary.
If your test framework supports it, I would make the test changes first but flag the test as expected-to-fail. Then upload the code fixes and remove the flag on that test.
Hopefully others will chime in with different solutions to this situation!
Upvotes: 0