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

Matthias Noback:
Local and remote code coverage for Behat
Feb 12, 2018 @ 09:45:43

In a new post to his site Matthias Noback has a post showing you how to, when using the Behat functional testing framework, to create local and remote code coverage metrics.

PHPUnit has built-in several options for generating code coverage data and reports. Behat doesn't. As Konstantin Kudryashov (@everzet) points out in an issue asking for code coverage options in Behat: "Code coverage is controversial idea and code coverage for StoryBDD framework is just nonsense. If you're doing code testing with StoryBDD - you're doing it wrong."

He starts off by talking about code coverage and why you might want it for the tests created through Behat. Code coverage metrics are usually associated with unit tests but having those numbers for the functional tests can be helpful too. He then covers the two pieces of the puzzle needed to gather the coverage numbers: an extension for the local coverage and one for the remote coverage. He shows how to get both of these installed, configured and used in the code to gather the results. Finally he shows how to use the phpcov tool to merge these results with the PHPUnit results to get a better overall view of coverage numbers.

tagged: local remote behat codecoverage metric phpunit tutorial testing

Link: https://matthiasnoback.nl/2018/02/behat-local-and-remote-code-coverage/

Anna Filina:
Testing Legacy PHP Scripts
Jan 30, 2018 @ 11:56:23

Anna Filina has a quick post to her site with some recommendations around testing legacy PHP scripts giving an example of a challenge to test a controller in isolation from the rest of the application.

I gave myself a challenge: to test a legacy "controller" in isolation, yet with minimal impact on the original code.

She starts with the example code she'll be testing and then works through the steps to effectively test it:

  • isolating it from the other functionality in the application
  • mocking a statically called method
  • requiring necessary files
  • executing the controller under test

The post ends with the test class she created showing how to evaluate the result of a call with one invoice in the billing system. She makes one comment at the end to answer the question "why not just refactor" but points out that, especially in larger legacy applications, that's just not always an option.

tagged: testing legacy script tutorial isolation mock unittest phpunit

Link: https://afilina.com/testing-legacy-php-scripts

Stefan Koopmanschap:
A rant about best practices
Jan 10, 2018 @ 13:19:02

Stefan Koopmanschap has shared a rant about best practices in a new post to his site. In it he shares some of his thoughts as presented in a lightning talk at the PHPAmersfoort meetup.

I have yet to talk to a developer that has told me that they were purposefully writing bad software. I think this is something that is part of being a developer, that you write software that is as good as you can possibly make it within the constraints that you have.

In our effort to write the Best Software Ever (TM) we read up on all the programming best practices: design patterns, refactoring and rewriting code, new concepts such as Domain-Driven Design and CQRS, all the latest frameworks and of course we test our code until we have a decent code coverage and we sit together with our teammates to do pair programming. And that's great. It is. But it isn't.

In the post he touches on a few main topics with his ideas for each:

  • Test Coverage
  • Domain-driven design
  • Frameworks
  • Event sourcing + CQRS
  • Pair programming
  • Refactoring + Rewriting

He ends the post with a suggestion to "consider all the best practices" when writing your code and developing applications. It's not just about applying them because they're defined as "best practices", it's about determining which of these practices make sense for your situation.

tagged: bestpractice rant opinion testing domaindrivendesign frameworks cqrs pairprogramming refactoring

Link: https://leftontheweb.com/blog/2018/01/10/A-Rant-About-Best-Practices/

TJ Miller:
An Approach to Testing Middleware
Nov 29, 2017 @ 09:06:19

TJ Miller has posted an article where he shares some suggestions about testing middleware in your applications. Since middleware is usually only executed as a part of the normal request/response cycle it is difficult to test in isolation.

I’ve always tested middleware in one of two ways, a unit test with mocks and asserting the callback in the handle method or integration tests on application routes.

[...] I wanted to find a simple approach that verified the following: middleware is active and configured correctly (global, group, single use) [and that the] middleware is functioning correctly

He briefly discusses the difference between unit testing and integration testing before showing how to set up unit tests for a Laravel-based middleware: a check for a JSON response, testing to ensure logging is working as expected and that a middleware is correctly assigned to a route.

tagged: testing unittest integration middleware laravel tutorial

Link: https://medium.com/@sixlive/an-approach-to-testing-middleware-c547fc942848

Laravel News:
Using Named Routes in a Lumen Test
Nov 21, 2017 @ 12:56:49

On the Laravel News site there's a quick tutorial posted showing you how to use named routes in Lumen in writing tests for your application.

When writing tests in Lumen, I recently discovered that the route() helper doesn’t work with tests out-of-the-box.

I prefer to define named routes and make requests against them in my tests. If you follow the Lumen documentation, the typical way that you make a request for a test [of the return of a JSON endpoint results in an error message]. [...] If you inspect things a little closer, you can see the issue: [...] Interestingly, the route doesn’t look quite right, and the router is returning the / route. It looks like the localhost part of the request isn’t being set, and the route isn’t matching. We can fix that by bootstrapping the request as Laravel does.

The post then walks you through the manual process of bootstrapping things so that routes are correctly resolved. This includes changes to the code for the base test case to handle the "boot" and set the path value for the request correctly.

tagged: named lumen route test request boot base testing tutorial

Link: https://laravel-news.com/using-named-routes-lumen-test

Mark Baker:
Extending final Classes and Methods by manipulating the AST
Nov 20, 2017 @ 10:38:32

Mark Baker has an interesting post to his site where he shares a suggestion for making it easier to create unit tests for some of the more difficult parts of your unit tests. In the article he shows how to extend final classes and methods by manipulating the AST (abstract syntax tree structure) of the current code under test.

We know that we should always write unit tests for our code, and mock dependencies; but that isn’t always easy when we need to mock classes define as final, or that contain final methods. This isn’t normally a problem when we’re only working with classes within our own libraries and applications, because we control whether they are final or not, and we can type-hint these dependencies to interfaces. However, when the dependencies that we use are from external libraries, we lose that control; and it can become harder to test our own classes if we do need to mock final classes and they haven’t been built to interfaces.

He talks about how one tool, Mockery, allows some of this with its functionality but can still cause issues when mocks are passed instead of actual class instances. He then starts on a solution he has been trying to implement - a mocking library that makes use of the PHP_Parser package to make it possible to modify the structure of the code itself, not just put a wrapper (mock) around it. He includes a bit of code showing how to use that and the BetterReflection library to do some class introspection, locate files for testing and how to the tool to "de-finalize" a class (make it no longer "final").

tagged: extend class method manipulate ast testing unittest final mockery tutorial

Link: https://markbakeruk.net/2017/11/19/extending-final-classes-and-methods-by-manipulating-the-ast/

Stefan Koopmanschap:
Your unit test methods need docblocks too
Oct 12, 2017 @ 11:48:02

In a post on his site Stefan Koopmanschap suggests something that, while not as commonly done as writing docblocks for the actual code, could help with a better understanding of the application's tests: writing docblocks on tests too.

If you've met me at any time in the previous 20 years and you discussed unit testing with me, chances are pretty big that I'd have told you that your test methods in your unit tests don't really need docblocks, because the test methods would be named in such a way that they were descriptive.

[...] Tests can be hard to real though, especially (but not exclusively) when testing legacy code. You may have lots of mocks to configure, for instance, or you may have several similar tests that are testing specific situations, edge cases or bugs you found along the way that you wanted to test before you them.

[...] Documentation is important. It lowers the bus factor, makes it easier to on-board new developers (or temporary external developers, waves) and makes you think about your own code in a different way. We're (getting?) used to documenting our software, but why not document our tests by giving it a bit more context?

He starts by talking about his process for testing (outline the desired tests then fill them in) and how adding docblocks helped him avoid a "nonsensical" test that wouldn't have provided much value. He then briefly discusses what would be useful to document in the test docblocks and provides some examples to illustrate. Finally he suggests something called "Docblock Driven Testing" where the docblock descriptions help to define what is to be tested and help to make more human-readable sense of what can be tested effectively.

tagged: unittest method docblock opinion testing definition

Link: https://leftontheweb.com/blog/2017/10/11/your_unit_test_methods_need_docblocks_too/

Laravel News:
Testing Laravel Middleware with HTTP Tests
Sep 28, 2017 @ 12:10:05

On the Laravel News site today there's a tutorial posted showing you how to test your middleware with HTTP tests and how they can help in more practical testing of your application.

In this post, I’d like to demonstrate a practical example of testing a middleware using HTTP tests. Testing at the HTTP level can make your tests more resilient to change and more readable.

On a recent episode of Full Stack Radio (#72) with Adam Wathan and Taylor Otwell, it was refreshing to hear them find a lot of practical value in HTTP testing. I have found HTTP tests to be easier to write and maintain, but did feel like I was Doing Testing Wrong™ somehow or that I was cheating by not mocking and isolating everything. If you haven’t listened to this episode yet, give it a listen, it’s full of good, practical testing advice.

He starts by laying out the example middleware he wanted to test, one for validating and securing webhooks coming back from the Mailgun service to handle incoming email. The code for the middleware is included, defining the handle, buildSignature and verify methods. He then uses the artisan command to make a test and provides the code to test and ensure that the middleware forbids requests that aren't POST.

tagged: laravel http testing middleware mailgun webhook post tutorial

Link: https://laravel-news.com/testing-laravel-middleware

Laravel News:
Testing With PhpSpec
Sep 18, 2017 @ 10:22:26

On the Laravel News site there's a new tutorial posted introducing you to testing with PhpSpec, a specification-driven testing tool that helps you model the specification your application needs to match.

PhpSpec is a testing tool based on the concept of emergent design using specification. You may have heard of Behavior Driven Development (BDD), and PhpSpec is a tool to use at the spec level or SpecBDD. We also mentioned PhpSpec in our recent roundup of Laravel Testing Resources, which includes ways you can incorporate PhpSpec into your Laravel workflow if you are interested in trying out SpecBDD.

If you’ve never tried PhpSpec, one of the things that I love about PhpSpec is that the process generates code for you and guides you through the SpecBDD process through the command line. Let me show you what I mean with a quick tutorial.

The tutorial then walks you through the installation of PhpSpec and how to run it from the command line before making any tests. They then walk through the configuration of the tool and share a sample workflow with seven steps including describing a specification, writing out expected behavior and verifying the behavior. Code examples (and command line calls) are included in each step of the way, defining an example "calendar" specification with the common functionality (add, subtract, divide, etc). The post finishes with some links to where you can find more information about PhpSpec and spec driven development.

tagged: phpspec specification testing calculator tutorial development

Link: https://laravel-news.com/testing-with-phpspec

Delicious Brains Blog:
Behind-the-Scenes: How We’re Automating Acceptance Testing
Aug 15, 2017 @ 10:57:04

On the Delicious Brains site Ian has written up a lengthy post sharing how they automate their acceptance testing for their PHP applications.

Have you ever had the joy of carrying out acceptance tests? For our team at Delicious Brains, testing our releases, in the past, has been one of the most dreaded tasks on the to-do list. We hold our plugins to a high quality standard so it’s a must but manual tests are brain-numbingly tedious and can take hours of expensive developer time.

Recently, we decided it was high-time to fix that. [...] Read on for more about how the automation of testing our plugins ahead of release is shaping up – including how we manually tested in the past and a look at some of the automated acceptance tests we’ve already implemented.

He starts by defining what acceptance testing is and how they're different from other types of testing. He then shows the manual method they were using to run their tests previously and what prompted the move towards automation. He talks about the tools that they use for their automated testing including Codeception and Docker. Configurations and scripts are included that make the automation work and some of the issues they came across during the move from manual to automated processes.

tagged: automated testing codeception docker tutorial setup configuration manual

Link: https://deliciousbrains.com/how-were-automating-acceptance-testing/