<?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>Sat, 25 May 2013 07:21:02 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Christian Weiske's Blog: Visualizing PHPUnit runs]]></title>
      <guid>http://www.phpdeveloper.org/news/16280</guid>
      <link>http://www.phpdeveloper.org/news/16280</link>
      <description><![CDATA[<p>
During some of his development, <i>Christian Weiske</i> found the tests for <a href="http://less-st.sf.net/">a project he was working on</a> too slow for comfort and figured there had to be a way to find the root cause:
</p>
<blockquote>
Running the specific test cases for the part of the application you're working on is easy and fast, but that does not tell you when changes in part A of the app break part B - which happened several times, and all just because I didn't want to wait 45 seconds again and again. So a solution was badly needed; tests should be as fast as possible; preferably < 10 seconds. Before being able to make the slow tests faster, I had to find out which of the 80 tests were slow.
</blockquote>
<p>
Tools like Jenkinks give more detail on test runs, but a normal <a href="http://phpunit.de">PHPUnit</a> install won't. So, he came up with a method that uses <a href="http://phing.info/">Phing</a>'s phpunitreport task to generate extra reporting easily. Here's some example screenshots: <a href="http://cweiske.de/tagebuch/images/phpunitreport/frames-overview.png">test results summary</a>, <a href="http://cweiske.de/tagebuch/images/phpunitreport/frames-error.png">test detail</a> and <a href="http://cweiske.de/tagebuch/images/phpunitreport/single1.png">single page views</a> of the same sort of data.
</p>]]></description>
      <pubDate>Mon, 02 May 2011 10:19:48 -0500</pubDate>
    </item>
  </channel>
</rss>
