Sammy Kaye Powers has posted the latest parts in his series looking at testing the PHP language with phpt tests. So far he's helped you compile PHP from source, run the test suite, learn about the phpt files and debug failing tests. He continues the series with two new posts:

• 05: Finding untested code
• 06: Submitting a PR to php-src

In the 5th part of his series he shows how to use the PHP gcov site to locate lines of code in the PHP language core that aren't tested yet, how to create a new test to cover it and generating a code coverage report to see how much you've tested. In Part 6 he shows you how to take what you've created and submit it back to the PHP project on GitHub as a Pull Request (no RFC needed) based on changes from your own forked repository.

Sammy Kaye Powers has a series of posts over on his site introducing you to testing the PHP language with .phpt tests. So far he's introduced the topic, shown how to run the tests and debugging failing tests.

If you've ever wanted to get involved with PHP internals, writing tests is a great way to get your foot into the door. The tests are written in PHP so you don't even need to know C to get started.

Each of the posts also comes with a screencast, narrated by Sammy, showing the information presented in the tutorial:

• 01: Compiling PHP from source
• 02: Running the test suite
• 03: All about .phpt files
• 04: Debugging failed tests

There's more to come in the series as he still plans to teach about how to fix current tests and how to eventually create your own. Stay tuned to his site for more tutorials in the series.

In a new post to his site long time PHP community member Ben Ramsey has officially announced PHP Testfest 2017, an event that gathers developers to write tests for the PHP language itself to help improve its quality and show them how to contribute back to the project.

For those who’ve been around the PHP community for a while, you’ll recall the successful PHP TestFest events that began after a discussion at PHP Quebec in 2008. Many user groups and mentors signed on to host and help with events, and a lot of folks became first-time contributors to the PHP project, helping improve our code coverage. It ran strong in a global sense from 2008 to 2010. After that, various groups (particularly the Brazilian groups) have continued the tradition.

A few months ago, at php[tek] in Atlanta, I mentioned to Michelangelo that I’d love to bring back PHP TestFest. Sammy had given an excellent talk on writing PHPT tests, and <a href="https://twitter.com/ellotheth/status/868583446498734084>Gemma tweeted a link to the old PHP TestFest wiki page. From there, things snowballed.

Ben the provides the details of the planned Testfest that will run for four months and can be worked on from anywhere, not just one single event. The plan is to have it run from September through December of 2017 and there's plenty of support to help out. Organizers can email for more help getting started. There's also a website, Google Group and IRC channel as well as tools and resources to help bring you up to speed on testing the PHP language with phpt tests.

On the SitePoint PHP blog Thomas Punt continues his series about how you can contribute back to the PHP language. In his previous post he talked about contributing to the PHP manual. In this latest part of the series he moves into something with a bit more complexity: contributing to the core of the language itself.

Previously, we covered contributing to PHP’s documentation. Now, we will be covering how to get involved with PHP’s core. To do this, we will be looking at the workflow for fixing a simple bug in the core.

Since submitting new features to PHP has already been explained pretty well, we will not be covering that here. Also, this article does not seek to teach PHP’s internals. For more information on that, please see my previous posts on adding features to PHP.

In this article he assumes you at least already have a working knowledge of the PHP source and how to locate/update code and execute it. He focuses instead on the bugfix process and workflow needed to:

• find a bug to fix
• create a test to reproduce the issue
• use a debugger to find the exact spot where the problem is
• and create a simple fix

In this case it's a pretty simple issue to correct, but there are much more complex things that would require more work than just a simple "if" check. This guide can help you get started on the correct workflow, however, and be sure you're handling things as the project expects.

Freek Lijten has a new post today continuing his look at the world of PHP extensions and focusing in on testing this time. He hopes to answer the question of what makes a good, effective set of tests to help increase the stability and quality of the extensions you write.

In my previous blog I took you through the process of getting PHP and extensions compiled, generating code coverage and running tests. What I did not talk about was what makes a good test. I hope to correct on this by adding this post and going into more detail on the actual writing of tests itself.

Using the same extension as before (enchant) he goes through the addition of a test for the enchant_dict_add_to_session function. He start by showing how much the function is currently tested (hint: none) and code coverage. He points out that 100% coverage is just one metric in a set that should be considered and not the final goal. He shares a simple test for the function that checks to see if a certain word exists in a dictionary. The coverage report shows all lines being executed, but there's a lot not tested, at least conceptually. He shows how to test "the spirit" of the function with additional tests for non-existent words, spell checking and if a word is not in the dictionary at all. PHP example code shows these tests kinds of tests to illustrate the steps he's talking about.

In his latest post Freek Lijten talks about PHP extensions, the upcoming PHP version - well, PHP7 - and the things that can be (and are being) done to help improve and prepare the extension ecosystem. In his post he walks you through the process of getting a PHP7 install set up, a sample extension set up and writing some tests to help improve it.

PHP7 is coming. And it is coming to a neighbourhood near you :) A couple of people started an initiative to ensure extensions will be running out of the box once PHP7 hits the shelves. The fun part: You can help too! No C knowledge is necessary (although it is fun to dive into PHP's internals!). This piece is a short intro to help you help PHP! Help triaging extensions, write tests, add documentation and who knows when you'll be diving into C code.

He's encouraging this work as a part of the recently launched GoPHP7 - Extensions initiative launched a while back. He starts by helping you get PHP7 installed (from source, compiled). Once that's installed and working, he helps you get an extension up and running, in this case the enchant extension. He shows you how to run the tests for the extension and how to write some tests to contribute back to the project. He includes instructions for generating code coverage reports, walks you through some sample code and a link to a page with more information if you get stuck.

Chris Jones has a new post today showing how you can use PHP 5.4's built-in web server to help test for memory issues in your application (and the language).

Rasmus mentioned on IRC how he ran the [command line] tests: simply renaming the ".phpt" test files as ".php", and invoking them through the CLI webserver. The SKIPIF sections get executed, but that doesn't affect the desired outcome of testing multiple HTTP requests with different input scripts. [Here] are some quick shell scripts I put together to automate testing the OCI8 extension with valgrind.

He uses the OCI8 extension as an example, showing how to set up these scripts to enable the execution of the tests, fire up the web server and execute Valgrind to help monitor the memory of the execution.

On the QaFoo.com site Manuel Pichler has posted a new tutorial about using unit testing, specifically with PHPUnit (really ending up on phpt) to test and be sure that your file upload handling is working correctly.

A question I am asked on a regular basis is, how you can test a file upload with PHP. In this blog post, I take a precise look at this topic and show you how to test your file uploads from within your standard testing environment, using widely unknown testing framework for PHP.

He shows how to use a custom $_FILES superglobal to mimic the upload process noting, however, that this won't work due to possible file handling on the backend. His alternative is to use a phpt test to push a raw posted file to the application and then check the results. He then shows how to take these functioning tests and drop them back into PHPUnit via it's "PhpTestCase" handling. You can find full code examples here.

If you've ever wanted to give back to the PHP project, but weren't sure quite how, Rafael Dohms has written up a post to make one of the options much easier to get into - writing PHPT tests for the PHP language.

The beauty about PHPT is that you need to know very little other than writing PHP code. A little knowledge into the inner workings of PHP will of course help you in finding areas of code that need testing, and how best to test them, but just knowing PHP is enough to start.

He leads you through a five step process that'll have you up and writing tests in no time - setting up your environment, looking for something to test, writing and executing a test and submitting the results back to the PHP project. He sprinkles in a few code bits and screenshots to help point you in the right direction.

In this new post to her blog Lorna Mitchell talks a bit about the upcoming TestFest event happening in Manchester next weekend and what she's learned about testing PHP to make things flow a bit smoother for her while there (and you, should you want to write tests in the future).

In preparation I decided it was high time to sit down and figure out what testing PHP is all about. People kept telling me it was easy but I had no clear picture of how all the pieces went together - there are different ways of doing the same thing and although I have been keen to get involved with testing for some time, I haven't been able to get started until now.

She looks at the automated tests as a part of the build ("make test") and some of the screens from the lcov testing results. She also recommends reading up on the phpt documentation to help you get going.