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

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/

Kevin Schroeder:
Magento 2 Performance on Docker (a preliminary test)
Aug 14, 2017 @ 09:58:17

Kevin Schroeder has a post to his site sharing some of the results from his initial testing with Magento in a Docker-built environment.

I can’t speak to the cost of Docker experts (I’m not one, but my experience is that once you get through the annoyance of the Dockerfile it doesn’t require much more advanced knowledge than a regular sysadmin), but I found the response interesting because my experience with Docker in production has been so good that I’ve Dockerized practically everything, including this blog. But this guy knows his stuff, and I give a lot of weight to his perspective. But my experience has been different.

Except in one place. Magento 2 on Docker on Mac is a horrible experience and it is specifically because of file system performance. But on Linux I’ve had good experiences. However, those experiences were with Magento 1 and not Magento 2. Magento 2 relies on the file system more than Magento 1 so it is quite plausible that Magento 2 is slow as molasses on Docker.

He decided that he'd try a different platform and see if the results were similar to those on an OSX system. He includes a list of four caveats and the setup including the fact that it is a "smoke test" (prelimary results) and that the rest was being done on a bit older machine. He shares the testing setup and what he used to test and compares the results to it running on "bare metal" (a normal custom setup server). His findings show that the "bare metal" instance ran only slightly better than the Dockerized version. He includes graphs for the requests handled, CPU usage and throughput from each of the tests executed.

tagged: magento docker performance testing results

Link: http://www.eschrade.com/page/magento-2-performance-on-docker

PHP Roundtable:
065: TestFest 2017
Aug 01, 2017 @ 12:19:09

The PHP Roundtable podcast, hosted by PHP community member Sammy Powers, has posted their latest episode - Episode 065: TestFest 2017 with guests Ben Ramsey, Rafael Dohms, Zoe Slattery and Cal Evans.

Adding tests to php-src is a great way to get involved with PHP internals. Don't know how to get started? You're in luck. TestFest 2017 is going to be a thing in September. User groups and individuals around the world are going to organize to learn how to add tests to PHP and become official internals contributors.

It has been 7 years since the last TestFest in 2010. We chat about how to get involved with TestFest 2017.

You can catch this latest episode either using the in-page audio or video player or by watching it directly on YouTube. If you enjoy the episode consider subscribing to their feed and following them on Twitter to get the latest updates when new shows are released.

tagged: phproundtable podcast ep65 testfest2017 testing event core language

Link: https://www.phproundtable.com/episode/php-test-fest-2017

Sammy Kaye Powers:
Writing tests for PHP source (Part 5 & 6)
Jul 25, 2017 @ 09:56:56

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:

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.

tagged: series testing language phpt untested gcov source pullrequest

Link: https://www.sammyk.me/finding-untested-code-in-php-source-writing-tests-for-php-source

ThePHP.cc:
Why Developers Should Not Code
Jul 19, 2017 @ 11:16:01

On thePHP.cc blog Stefan Priebsch offers up an interesting opinion about code, developers and understanding - developers shouldn't code.

The ultimate problem with program code seems to be that no human really understands it. Sure, we can look at a short piece of code and be relatively clear on what it does, but can we still do the same thing with programs that span tens or even hundreds of thousands of lines?

[...] Well, sometimes I get a strong feeling that there is a shortage of good programmers, because I often find myself looking at legacy code, being unable to tell what it does, at least with reasonable certainty. [...] Personally, I already consider code to be problematic when there is a reasonable amount of doubt as to what it does (and why it exists). To me, uncertainty and discussions are a sure sign of bad code. Call me picky, but years of experience have taught me that this level of strictness makes sense.

He suggests that the fact a developer cannot recognize what current code is doing doesn't make you a poor developer, but the opposite. He talks some about the meaning of the word "code" and how it is written for a machine to understand, not a human. He ends the post talking about testing your code to provide an "executable specification" and, despite having this, a human-readable spec is still a requirement (like it or not).

tagged: developer code opinion specification testing

Link: https://thephp.cc/news/2017/07/why-developers-should-not-code