12

In reference to the patent: WO2013115797A1

This patent from Hewlett-Packard relates to automatically running a set of tests against a "plurality of code changes" to determine "the failed code change" by:

"removing at least one of the plurality of code changes from the subset each time the subset fails the set of tests"

The "management tool" claim reads like the use of a Continuous Integration tool, e.g. CruiseControl available since 2001.

The "decision engine" claim reads like the use of git bisect run, available since at least 2007, possibly earlier.

The earliest article I can find on the web about the use of git-bisect's run feature is "An introduction to the git bisect feature" by Nicolas Trangez, published in August 2007, an excerpt of which is:

No[w] the magic can start:

$ git-bisect run ./testcase.sh

running ./testcase.sh

d6514e8d9fe55827fe78d650548d948a4647fc50 is first bad commit

bisect run success

Exactly, like it should, it figured out commit 16 [...] broke our application.

In 2009, Atlassian's Justus Pendleton blogged about using git bisect run.

Since early 2010 Mozilla have provided the open source mozregression tool, used as a regression range finder for their nightly builds.

Does anyone have examples of git bisect run (or similar) used in an automated manner, perhaps as part of a continuous integration/delivery tool, prior to 2012?

Improve this question

5 Answers 5

Reset to default
5

The Phoronix Test Suite has offered automated bisect support using Git in an automated manner since 2008~2009. Some of the details via http://www.phoronix.com/scan.php?page=article&item=linux_perf_regressions&num=1 among other articles.

Improve this answer
4

The following research paper from 1999 seems very related:

Andreas Zeller. "Yesterday, my program worked. Today, it does not. Why?" In Proceedings 7th European Software Engineering Conference / 7th ACM SIGSOFT Symposium on the Foundations of Software Engineering. Lecture Notes in Computer Science 1687, Springer 1999, ISBN 3-540-66538-2, pp 253-267.

Abstract

Imagine some program and a number of changes. If none of these changes is applied (“yesterday”), the program works. If all changes are applied (“today”), the program does not work. Which change is responsible for the failure? We present an efficient algorithm that determines the minimal set of failure-inducing changes. Our delta debugging prototype tracked down a single failure-inducing change from 178,000 changed GDB lines within a few hours.

Links:

Improve this answer
1
  • 1
    It quotes Brian Ness' 1997 paper Regression containment through source change isolation "Their so-called regression containment is activated when the automated regression test fails. The method takes ordered changes from a configuration management archive and applies the changes, one after the other, to a configuration until its regression test fails."
    – Lovell Fuller
    Mar 7, 2015 at 20:40
2

During the "5th Google Test Automation Conference" (October 28-29, 2010), Chirstian Couder presented a talk named "Git Bisect and Testing", where he describes the use of git-bisect as a way to find the first "bad commit" that generates a regression.

Abstract

"git bisect" is a command that is part of the Git distributed version control system. This command enables software users, developers and testers to easily find the commit that introduced a regression. This is done by performing a kind of binary search between a known good and a known bad commit. In the manual mode, at each step, a commit is checked out, and the user is asked to test the current state of the code. This can be automated with "git bisect run", so that a simple script or a command instead of the user can test the current state. Some developers out there are very happy with automated bisection, because it saves them a lot of time, it makes it easy and worthwhile for them to improve their test suite, and overall it efficiently improves software quality. "git bisect" makes test suites more useful and in turn test suites make it easier and simpler to use "git bisect". So using them together creates a virtuous circle. Another nice thing is that "git bisect" and test suites can be used together to reduce the number of tests that have to be performed while improving test coverage. In the end, bisecting can be an important part of a software quality process.

relevant slide

Improve this answer
1
0

I believe I have a patent, originally filed Sept 30, 2010, that helps cover this:

US8489929

Improve this answer
0

I implemented a Google internal variant of bisect in 2008. There are no external references to it, but the code might still be lurking around at Google.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .