Debugging with git bisect

Via Sebastian Bergmann’s blog I’ve learned about git bisect and how it can used for debugging.  Sebastian demonstrates the functionality together with PHPUnit.  I am a git newbie, so that was quite interesting for me.

git bisect can be used to find the change that introduced a bug. It does so by performing a binary search on the list of commits between a known good and a known bad state of the repository. A tool such as PHPUnit can be invoked at each step of the binary search to check whether or not the current state is broken.

Here is a shortcut on how to actually use it:

$ git bisect start
$ git bisect good someVersion
$ git bisect bad someOtherVersion
$ git bisect run someCommand -with SomeArgument

There are, of course, more resources online covering the feature.  I found this section of the Git Community Book helpful.  Hopefully, I’ll remember about it when I actually need it.

Unit tests with CakePHP

I’ve spent a large part of yesterday setting up the testing environment for a CakePHP project.  As always, every time I do something that I have done before, I wanted to do it better, using all the experienced that was acquired previously.  And this often leads to the discovery of new things – both good and bad.  Here is a record of what I’ve learned yesterday.

Continue reading Unit tests with CakePHP

On software testing

The software is checked very carefully in a bottom-up fashion. First, each new line of code is checked, then sections of code or modules with special functions are verified. The scope is increased step by step until the new changes are incorporated into a complete system and checked. This complete output is considered the final product, newly released. But completely independently there is an independent verification group, that takes an adversary attitude to the software development group, and tests and verifies the software as if it were a customer of the delivered product. There is additional verification in using the new programs in simulators, etc. A discovery of an error during verification testing is considered very serious, and its origin studied very carefully to avoid such mistakes in the future. Such unexpected errors have been found only about six times in all the programming and program changing (for new or altered payloads) that has been done. The principle that is followed is that all the verification is not an aspect of program safety, it is merely a test of that safety, in a non-catastrophic verification. Flight safety is to be judged solely on how well the programs do in the verification tests. A failure here generates considerable concern.

The above was written by R. P. Feynman, in Feynman’s Appendix to the Rogers Commission Report on the Space Shuttle Challenger Accident, 1986. More than 20 years ago. Much recommended reading.

Found via Richard Feynman, the Challenger Disaster, and Software Engineering.