The high-level goal of this exercise is to improve git proficiency and to learn about systematic debugging, using git bisect.
Team up in groups of size 2, and self-assign to a group (In-class1-Git groupset) on Canvas. (If you are in a Canvas group of size 1, you can still submit.) In the past, groups found a pair-programming set up (in person or using screen-sharing for remote work) to be beneficial.
Clone the following git repository and read its README.md file: https://bitbucket.org/rjust/basic-stats
Test your set-up: compile and test the application. Note that one test failure is expected on the most recent commit of the main branch.
Check out the version v1.0.0 (git checkout v1.0.0), and compile and test the application again. Note that all tests are expected to pass on this revision.
The developers of this application followed reasonable development practices and used a test-driven approach until they published the first release. Everything just went haywire from there – a lot of late-night, sleep-deprived, pizza-and-drinks hacking.
Unfortunately, the developers introduced a defect at some point after the first release (v1.0.0), which has existed in the code since. While the developers thought about and implemented some automated testing, their automated testing infrastructure did not catch the defect, and since they were so excited about coding, they never manually checked a single test run. The testing infrastructure is a nightly run cron job, which executes the following command: ant clean test || reportBug
This command builds the application from scratch and runs all tests using Ant. If ant fails (i.e., returns a non-zero exit code), then the reportBug command notifies the developers via email; otherwise nothing happens. Note that || is a short-circuit OR operator: the command on the right-hand side (reportBug) is only executed if the command on the left-hand side (ant clean test) fails.
Checkout the most recent commit on main (git checkout main) and run: ant clean test. Note the test failure and figure out why the testing infrastructure described above does not catch this failure,i.e., does not send an email (hint: run ant clean test || echo "Test failure" to simulate the error reporting).
Familiarize yourself with the version control history and determine the number of commits between v1.0.0 and main (current HEAD revision). Include v1.0.0 and HEAD when counting, and note the command(s) that you used to automatically compute this number.
Familiarize yourself with the git bisect command and use it to identify the commit that introduced the defect between version v1.0.0 and main. Note the commit hash and log message of the defect-inducing commit. Verify that you correctly identified the defect-inducing commit. You may automate git bisect with a script.
Why does the described automated testing infrastructure not catch the test failure? How could you improve it?
How many commits exist between version v1.0.0 and main (including v1.0.0 and main)? List the command(s) that you used to automatically compute this number.
Which commit (commit hash and message) introduced the defect? How did you verify that this commit indeed introduced the defect?
How many commits, not including v1.0.0 and main, did git bisect analyze before finding the first failing commit? List all steps (calls to git bisect) you took; these steps must be executable by the staff.
What is the best-, worst-, and average-case run-time complexity of git bisect to return the defect-inducing commit? Why?
Which git command can you generally use to undo a defect-inducing commit – like the commit you identified in question 3? Can you undo this defect-inducing commit using the proposed git command? Briefly explain what problem may generally occur when undoing a commit and what best practices mitigate this problem.
One team member should upload the deliverables to Canvas, via the Canvas submission site for this course.