<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Wed, 19 Jun 2013 10:53:38 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Sebastian Bergmann's Blog: Debugging with Git and PHPUnit]]></title>
      <guid>http://www.phpdeveloper.org/news/16082</guid>
      <link>http://www.phpdeveloper.org/news/16082</link>
      <description><![CDATA[<p>
<i>Sebastian Bergmann</i> has a recent post about how you can use <a href="http://sebastian-bergmann.de/archives/911-Debugging-with-Git-and-PHPUnit.html">git and PHPUnit to debug</a> your application and find out when the offending code was added.
</p>
<blockquote>
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 <a href="http://phpunit.de/">PHPUnit</a> can be invoked at each step of the binary search to check whether or not the current state is broken.
</blockquote>
<p>
He gives an example of some failing tests where the return value isn't equal to what it should be. Finding the hash of the initial commit, he compares that with the "git bisect" command to point to the "good" and "bad" points in the timeline. Command line examples are also included in the post.
</p>]]></description>
      <pubDate>Tue, 22 Mar 2011 13:04:15 -0500</pubDate>
    </item>
  </channel>
</rss>
