|
|
|||||
|
|
|||||
|
|
Linking JUnit test cases with your bug tracker Bug fixing through unit testingWhen a bug is entered in a bug tracking system and its thought to be a real bug, the first thing that should happen, in an ideal world, is that someone writes a new JUnit test case to demonstrate the bug. If the bug cannot be reproduced, never mind you've gotten some more JUnit testing code for your trouble. If it does manage to reproduce the bug, then its a real bug and you've a JUnit test case that demonstrates whether its been fixed or not. Lets assume that a new production release can only occur when all the JUnit test cases pass. This is the default in Maven right now - though it can be disabled to allow builds, which don't pass all the unit tests, to be created for internal purposes such as nightly builds etc Now the release build will fail unless all the know, reproducable bugs are fixed. Indeed following this process it means that all known, easily reproducable bugs would never slip through into any release ever again. So already this mechanism provides excellent quality control. Linking the bug unit test cases with your bug trackerNow if the original bug in the bug tracker is associated with the JUnit test case, then as soon as a build/release is done that fixes the bug, the bug tracker could automatically mark the bug as fixed and link the version of the fix to the current build/release number. (This could get kinda clever where the test has to run on every platform combination that are part of the unit testing to be considered fixed). So the fact that a bug is fixed and when the bug actually got fixed would be automatically maintained by (say) a simple Maven and JIRA plugin. What would be even cooler would be Maybe the Maven and JIRA integration could be clever enough to also grep the source control change log for each build/release for mention of the unit test case or bug reference number and link the details of the changes of what changed to fix the bug, into JIRA as well. Also as part of the release, the Maven and JIRA plugin could auto generate user documentation listing all the bugs that were fixed, details from JIRA of what the bugs were (maybe a link to the publicly accessible JIRA repository) and links to the source code repository to show all the file changes that occurred to fix the bugs. So we could have a totally cool and automated bug tracker, source control system and release management integration. This integration should help improve the quality of the data in the bug tracker (saying exactly when bugs get fixed and what really did change), in the source control system (what changes were connected to what bugs) and in all of this it should take less developer time than now to actually use on a day to day basis. We just need those JIRA folks to write a groovy Maven plugin :-) Workflow of using JUnit and your bug trackerIts very common in corporate environments to have seperate roles, a group of testers in a QA department testing software and developers hacking the code. The JUnit-bug tracking mechanism works very well. The people testing the code can write tests cases to investigate behaviour, particularly when trying to replicate customers bugs. Then once the unit test case can reproduce the bug it can be assigned to a developer to fix. This JUnit-bug tracking pattern also works very well in open source projects. If a (technical) user finds any kind of problem with an open source project they can simply submit a new unit test case demonstrating the problem. Where possible we should encourage our technical users to submit unit test cases whenever they find any kind of bug or feature.
|