Drupal 8 ships with a lot of helpful out-of-the-box analysis tools which will help you to understand the overall quality of your code. Now we have both PHPUnit and Simpletest. The group behind Drupal's CI & testbot keeps on improving the tools in place. But what if we want to go one step ahead and use tools which have been adopted by the wider PHP community as well?
legovaer
Levi has been developing PHP applications for about 15 years now. 5 years ago, he had his first hands-on experience with Drupal and it was love at first sight. When he needs to perform a single task more then once, he'll be looking for a way to automate it. He's a perfectionist and that's one of the main reasons why he's spending so much time on code analysis and TDD. On Drupal.org you will find his contributions in several modules:
- Scheduler module (Port D7 module to D8)
- Drupal Symfony Inject (Co-maintainer)
- Validators (Maintainer)
Audience
This session is intendended for:
- (experienced) module developers who have been working with Simpletest and/or PHPUnit
- Both Drupal 7 as Drupal 8 developers
- Module maintainers that would like to decrease their amount of bug reports
What you will learn
After the session, you will understand how you can generate a code coverage report of your own module's codebase and even better: you will be able to get it generated automatically using Travis CI.
Code Coverage
One of the most important analysis tools we are currently still missing is the visibility of our code coverage reports. It's a powerful tool which has been in PHPUnit for quite a while. Why aren't we using this tool in the Drupal community? That's exactly what I've been thinking about one year ago.
I started contributing to the PHPUnit framework and developed several changes into the framework which allow us, the Drupal community, to generate code coverage reports on both our PHP Unit tests as our Simpletest codebase. Yes, Simpletest is included as well!
During my session, I want to share to other experienced developers how they can perform different analysis on their codebase to make sure that they're not introducing any regression issues. During the development of the D8 version of the Scheduler module, we had to perform an analysis on which code was being tested by our automated tests. We found this quite time consuming to do manually, that's where Travis came into play.
Scheduler Module
Today we have automated tests for the Scheduler module which displays us which code has been covered by the tests we have written. This allowed us to improve the overall coverage of the tests and decrease the amount of bug reports.
At this point in time, we're even working on a tool which will automatically send the coverage report to coveralls.io.
One of the maintainers of the Scheduler module's quote after introducing the automated coverage report:
WOW! That is fantastic! What a brilliant idea. The coloured lines of code make it beautifully easy to view the coverage. This is great work. -- Jonathan1055
References:
- https://github.com/legovaer/scheduler/tree/7x-coverage-report -- Adding awesome badges to the module's README file
- https://rawgit.com/legovaer/scheduler/7x-coverage-report-reports/index.html -- Today's coverage report of the D7 scheduler module
- https://www.drupal.org/node/2112869 -- The issue in the Scheduler module where it all started
- https://www.drupal.org/node/2622922 -- The issue in DrupalCI: Modernizing Testbot Initiative which is asking for code coverage support