News Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

NetTuts.com:
Test Code Coverage From Myth to Reality
March 31, 2014 @ 11:50:09

There's a good post over on the NetTuts.com site today talking about unit testing, the myths around code coverage and why it may not be as important as you think.

Most cubicle workplaces disappeared and programmers started loving their craft. With the advent of Agile techniques and the Software Craftsmanship movement, many new tools emerged to help the programmer and the process. TDD is slowly becoming the de facto way of writing code and the secrets of SCRUM or Kanban were revealed even to the programmers in the darkest corners of the cubicle world. Automated testing and test driven development (TDD) are some of the essential techniques Agile provided to us programmers. And a tool that comes with those methodologies is used to produce test code coverage, which is the topic of this article.

The article starts with a brief definition of code coverage and gets right into an example class, PHPUnit test and the results of a code coverage generation. They show both output options, the text-only output and the full HTML output with clickable links and visualization of the covered lines of code. There's also an example of generating the coverage inside an IDE (PHPStorm). The post finishes with a look at the myths of code coverage including: "100% covered is bug free" and that "gaming the system" is pretty easy.

0 comments voice your opinion now!
codecoverage unittest phpunit tutorial introduction

Link: http://code.tutsplus.com/articles/test-code-coverage-from-myth-to-reality--cms-20442

Anna Filina:
Full Test Coverage is Impractical
May 23, 2013 @ 12:06:34

In her latest post Anna Filina proposes that full test coverage is an impractical way to measure the quality of your software. It can provide a false sense of security, even if the tests are poorly written.

Many developers claim that to achieve high quality software, developers must create automated tests that ensure that all possible execution routes have been covered. This is also known as full path coverage. I will argue that different types of software require different testing approaches and that full path coverage is impractical in almost every case. Too many tests simply create clutter.

She looks at how it's impractical to expect that all tests will be written efficiently or even correctly. Even simple tests are enough to show up on code coverage reports but may only be painting part of the picture. She also notes that not all software can be tested the same way - things like APIs require different testing skills/methods than something like consumer software.

In the end, there are no exact rules on how much to test. The most important thing to keep in mind is that writing tests for the sake writing tests is futile and costly. [...] Focus on building great software. Tests are a tool to make it better. Just don't overdo it.
0 comments voice your opinion now!
full testing codecoverage quality software impractical opinion

Link: http://annafilina.com/blog/full-test-impractical

Codeception:
Codeception released with CodeCoverage support
January 09, 2013 @ 11:14:19

The Codeception testing tool has released a new major update with some interesting new features - the expected feature for generating code coverage reports (similar to other tools) but there's also the idea of "remote code coverage" introduced.

There is no magic in local codecoverage. XDebug and PHP_CodeCoverage libraries do their job. The tricky thing is remote codecoverage. We attach small script into application's front controller. When a special header is sent this script starts to collect coverage information. And in the end of tests, this data is merged, serialized and sent back to Codeception. So you can test and collect coverage report even on staging servers in real environment.

They also mention a few other updates in the release - new Redis and MongoDb modules, UX improvements and the normal bugfixes. You can find out more about the code coverage feature in their manual or just about the project in general from the main site.

0 comments voice your opinion now!
codeception unittest tool codecoverage remote report update


Derick Rethans' Blog:
Xdebug's Code Coverage speedup
September 23, 2011 @ 09:56:33

Derick Rethans has a new post to his blog today talking about some work that's been done to speed up XDebug's code coverage generation. Changes in the coming 2.2 release have some improvements that make things perform better and put less stress on PHP in the process.

Code coverage tells you how much of your code base is actually being tested by your unit tests. It's a very useful feature, but sadly, it slows down PHP's execution quite a lot. One part of this slowdown is the overhead to record the information internally, but another part is because I have to overload lots of opcodes. (Opcodes are PHP's internal execution units, similar to assembler instructions) They are always overloaded even if code coverage is not used, because it's only safe to overload them for the whole request.

These changes were from a combination of contributions from Taavi Burns and a new ini setting that will allow you to enable or disable the code coverage in XDebug. Benchmarking shows a good amount of time reduction in coverage runs - dropping anywhere from a few seconds to over a minute. He also mentions the idea of "modes", shortcuts to predefined settings for different types of reporting (like "profiling" or "tracing").

0 comments voice your opinion now!
xdebug codecoverage speed improvement opcode contribution benchmark


Sebastian Bergmann's Blog:
Towards Better Code Coverage Metrics in the PHP World
June 20, 2011 @ 08:10:57

Sebastian Bergmann has a new post to his blog talking about some of the future plans for better code coverage metrics for PHP applications (not just the statistics that we have now as generated from PHPUnit runs combined with Code_Coverage PEAR package and Xdebug).

Xdebug currently only supports what is usually referred to as Line Coverage. This software metric measures whether each executable line was executed. Based on the line coverage information provided by Xdebug, PHP_CodeCoverage also calculates the Function / Method Coverage software metric that measures whether each function or method has been invoked.

The various kinds of coverage they're planning the in future include statement coverage, branch coverage (boolean evaluation), call coverage, path coverage with an alternative of linear code sequence and jump coverage (LCSAJ).

0 comments voice your opinion now!
codecoverage metrics analyze code xdebug phpunit phpcodecoverage pear


Volker Dusch's Blog:
Dealing with segfaults while PHPUnit code coverage generation for CI
April 14, 2011 @ 11:55:13

Volker Dusch has a new post to his blog looking at handling segfaults during code coverage generation that might come up during your continuous integration process (with PHPUnit flavor unit tests).

About half the "Build failed" mails I've gotten from Jenkins in the last two weeks where not due to me breaking the tests but just PHPUnit segfaulting. "Wait! I know PHPUnit can't segfault!", only PHP itself can. And it does, quite often. For some reason that probably has to do with using PHP 5.2.OLD it doesn't survive generate the clover.xml file or the HTML report about 20% of the times it's being run.

He finds a solution to keep this from happening - not correcting the segfault as much as running the testing again to get it to pass. He wraps the call to PHPUnit inside of a simple shell script that tries to execute the PHPUnit testing suite as long as a segfault isn't thrown. If something was seriously broken, this could cause all sorts of problems, but in theory it's a simple hack that gets the job done.

0 comments voice your opinion now!
jenkins phpunit build continuousintegration codecoverage segfault


Volker Dusch's Blog:
Running your Unittests everytime you save a file
December 23, 2010 @ 11:55:23

Volker Dusch has a suggestion for all of those developers out there really concerned about the quality of your code - consider running your unit tests every time you save a file with the help of a tool called PyWatch.

At the moment he placed the Idea in my head that i want my testsuite to run every time a file changes anyway, let someone else figure out how that is triggered. Well, someone did figure that out, thank you. It's called "PyWatch" and is a simple python script that monitors files for changes and executes a script if one has changed.

Obviously you wouldn't want to keep this going for larger code bases (the potential for overlap is horrible) but it could be quite useful when doing test-driven development to save yourself some hassle at the outset. He includes the commands you'll need to get things running and a simple PHP script that points the PyWatch instance to the correct files.

2 comments voice your opinion now!
unittest pywatch save file phpunit codecoverage


PHP.net:
TestFest 2010
June 24, 2010 @ 08:57:56

A new announcement on the PHP.net site today talks about this year's TestFest, an even to help increase the code coverage of the tests on the PHP language itself.

During TestFest, PHP User Groups and individuals around the world organize local events where new tests are written and new contributors are introduced to PHP's testing suite. Last year was very successful with 887 tests submitted and a code coverage increase of 2.5%. This year we hope to do better.

The SVN repository and reporting tools are back again this year (a great improvement over years past) with the new additions of an automated test build environment and screencasts showing the tools in action. You can find out more about this year's event on the TestFest page of the PHP.net wiki (including finding an even near you to participate in).

0 comments voice your opinion now!
testfest2010 unittest codecoverage


Sebastian Bergmann's Blog:
Code Coverage Dashboard
April 05, 2010 @ 09:28:00

In a new post to his blog Sebastian Bergmann talks about a new "dashboard view" that's been added to work with the PHPUnit testing suite - PHP_CodeCoverage. He talks more about what it has to offer:

PHP_CodeCoverage is a library that provides collection, processing, and rendering functionality for PHP code coverage information. Its architecture has support for multiple backends for collecting code coverage information (currently only support for Xdebug is implemented) and for reporting code coverage information (for instance using Clover XML or as an HTML report).

The dashboard shows the code's class coverage distribution, class complexity, top project risks and the least tested methods to help you narrow down potential issues in your application. Here's an example of the output.

0 comments voice your opinion now!
codecoverage phpunit phpcodecoverage dashboard


Sebastian Bergmann's Blog:
CRAP in PHPUnit 3.5
January 12, 2010 @ 11:14:03

As Sebastian Bergmann mentions in his latest post, he's changed up how the code coverage functionality is handled in PHPUnit so that he can add something new - CRAP.

PHP_CodeCoverage is a component that provides collection, processing, and rendering functionality for PHP code coverage information. [...] Having all code that deals with code coverage in a separate component allows for easier development and better testing. The first result of these improved development conditions is a small new feature that I recently implemented, the support for the CRAP metric.

Your code's CRAP (Change Risk Analysis and Predictions) scoring combines the idea of cyclomatic complexity and code coverage statistics to try to guess at how difficult any given piece of code would be to maintain. You can see an example here - the lower the number the better.

0 comments voice your opinion now!
crap cyclomatic complexity codecoverage phpunit unittest



Community Events





Don't see your event here?
Let us know!


series update install library deployment tips opinion symfony introduction podcast interview release laravel list language framework zendserver package api community

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework