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

Matthias Noback:
Mocking at architectural boundaries: persistence and time
Feb 22, 2018 @ 11:07:35

In a new post to his site Matthias Noback takes a look at unit testing your code and how it can be "dangerous" if you use mocking/doubles in the wrong way (not effective testing). Instead, he makes the recommendation to mock at architectural boundaries, specifically looking at mocking persistence and time handling.

More and more I've come to realize that I've been mocking less and less. The thing is, creating test doubles is a very dangerous activity.

[...] For example, by creating a test double for the EntityManager, we're assuming that it will work well with any objects we'll pass to it. If you've ever debugged an issue with an EntityManager, you know that this is a bad assumption. Anything may go wrong: a mistake in the mapping, missing configuration for cascading persist/delete behavior, an issue with the database credentials, availability of the database server, network connectivity, a missing or invalid database schema, etc.

He then gets into the concepts behind mocking across the "architecturally significant boundaries" and what kind of functionality this involves. He then gets into the two different examples sharing some of the basic concepts and test examples for evaluating persistence and time handling. He finishes up with a look at some of the potential consequences ("outcomes" is really a better word) of refactoring your tests and code to follow these ideas.

tagged: mock unittest architectural boundary persistence time tutorial

Link: https://matthiasnoback.nl/2018/02/mocking-at-architectural-boundaries-persistence-and-time/

Alejandro Celaya:
Mutation testing with infection in big PHP projects
Feb 19, 2018 @ 09:39:58

Alejandro Celaya has a post on his site that shows how to use a less well-known testing tool - mutation testing - to test for variations on the "good" and "bad" data paths. In this article he makes use of the infection library that replaced the previously active Humbug library.

There's no doubt that having tests in a project allows you to find potential bugs earlier and more easily.

Lots of OSS projects require a minimum code coverage in order to accept new pull requests from contributors, and proprietary projects also tend to have some sort of continuous integration workflow which requires certain metrics to be fulfilled in order to get builds passing. However, the code coverage can lead to a false sense of security, which makes you think that if a certain class has a 100% code coverage, it is also 100% bug-free.

This is not always true since you could be calling a method and yet not being properly testing its output or its real behavior. The code coverage will mark it as covered, but you might introduce a bug and still have a green test. This is where mutation testing comes in.

He starts by briefly introducing the concepts of mutation testing and showing how to get the infection library installed and configured. He then gives a guide on running the tool and some of the command line options that can be used to configure threading, having it only run on covered code and setting the log verbosity. He then offers some advice on troubleshooting the use of the tool and how phpdbg is used to generate reports.

tagged: unittest mutation testing infection tutorial project

Link: https://blog.alejandrocelaya.com/2018/02/17/mutation-testing-with-infection-in-big-php-projects/

Laravel News:
Defense Programming: Anticipating Failures with Tests
Feb 14, 2018 @ 09:45:25

On the Laravel News site there's a tutorial posted that makes some suggestions about how to anticipate application failures by using effective unit testing.

When you start working on a new feature, it is wise to plan out not only how it is expected to work, but what happens if something fails. Taking the time up front to anticipate failure is a quality of a great developer.

[...] Since we don’t know when a dependency might fail, it’s best to plan for failure by having tests so we can be more confident in failed states. Laravel can help us write tests that plan for failure using real-time facades.

In their example, they create a simple "article" repository class that makes use of a HTTP client to fetch the information for each article (by ID). In this case the client is Guzzle. They then add a singleton to the configuration to fetch the API class and show how to implement it in a controller. With this structure, they then move on to testing for failure via real-time facades and mocking a Guzzle response using a "Client" facade instead of calling it directly.

tagged: failure test defensive programming unittest laravel tutorial

Link: https://laravel-news.com/defense-programming-anticipating-failures-tests

Robert Basic:
Mockery partial mocks
Feb 05, 2018 @ 11:18:08

Robert Basic has a quick post to his site where he shows how to use partial mocks in Mockery, a useful tool for unit testing in PHP applications.

In dealing with legacy code I often come across some class that extends a big base abstract class, and the methods of that class call methods on that big base abstract class that do an awful lot of things. I myself have written such classes and methods in the past. Live and learn.

One of the biggest problems with this kind of code is that it is pretty hard to test. The methods from the base class can return other objects, have side effects, do HTTP calls…

He gives an example of a model that includes a method returning a database connection. In the child class of this the method that he's wanting to test includes a call to this method, making it difficult to test in isolation. He then shows how to make a partial mock of the child class that, be definition, returns a mocked PDO instance instead of the real PDO instance. All other methods will be passed through to the real class.

tagged: mockery unittest partial mock class abstract tutorial

Link: https://robertbasic.com/blog/mockery-partial-mocks/

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

Brandon Savage:
Don’t write useless unit tests
Jan 17, 2018 @ 10:44:42

Brandon Savage has a quick post to his site sharing some advice around the testing of your application, more specifically around unit tests: don't write useless unit tests. He starts with an example of a test that, while moving the project closer to the 100% coverage number, is mostly useless.

Too often, in the search for 100% unit test code coverage, I see tests like this get written. They don’t serve a practical purpose, except to meet the test coverage goal. Worse, they don’t actually improve the quality of the application.

Instead of writing a unit test here, we would be better served by writing an integration test, or a functional test. These tests would require us to interact directly with the database, but would provide far more valuable information about the health and status of our application. A useless unit test provides us with little if any benefit; a useful functional test provides us with tremendous advantages.

He includes the code for the test and talks about what's wrong with the approach and how it could potentially be handled better. He suggests that writing good, useful tests requires both skill and determination and the avoidance of tests that actually increase the quality of the overall test suite.

tagged: useless unittest tutorial example functional test

Link: https://www.brandonsavage.net/dont-write-useless-unit-tests/

Sergey Zhuk:
Test Coverage: Integration Between CodeClimate and Travis CI
Jan 11, 2018 @ 09:42:11

In a post to his site Sergey Zhuk shows you how to get up and running on Travis-CI and Code Climate for generation unit test coverage with an integration between the two services.

When you maintain an open-source project it is considered a good practice to have a high test coverage, so the community can feel safe about using your code in their projects. There are some services that can analyze your code quality and provide some feedback about it. One of the most popular is Code Climate. This service doesn’t run your tests, but you can use one of CI tools to run them and then send their result to Code Climate. This article will show how to use Travis CI to run your tests and CodeClimate to get your test coverage.

The rest of the tutorial is broken down into five steps (well, five-ish - some have sub-steps):

  • Get Your CodeClimate Reporter ID
  • Add Your Code Climate Token To Travis CI
  • Add CodeClimate Test Reporter Package
  • Update phpunit.xml
  • Update Travis CI Config To Send A Report

Each section includes the configuration changes to the .travis.yml or phpunit.xml configuration files you'll need to make to connect the services and generate the reports automatically.

tagged: unittest coverage metric travisci codecliemate integration automatic tutorial

Link: http://sergeyzhuk.me/2018/01/11/travis-with-codeclimate/

Sameer Nyaupane:
PHP Test Driven Development Part 2: Unit Testing
Dec 18, 2017 @ 13:39:07

On the HackerNoon site Sameer Nyaupane has posted the second part of his series on test-driven development in PHP focusing on unit testing and sharing some best practices around creating effective tests.

All right, welcome to part 2 of “PHP Test Driven Development” series. Today we will go through the PHPUnit setup in detail.

We will be using the Laravel framework to make it easier for us to get started. It will also help me to show you how to do testing for real life applications. I will assume you have used Laravel before. This will help me focus on the testing side and make the tutorial easier to grasp.

The tutorial then walks you through the setup of a new Laravel project and the inclusion of PHPUnit before getting into the tests themselves. It also shares a PHPUnit configuration example and the creation of an example tests with a simple assertion.

tagged: tutorial testdriven development tutorial series part2 unittest

Link: https://hackernoon.com/php-test-driven-development-part-2-unit-testing-c327ba3fbf14

Robert Basic:
Mockery return values based on arguments
Dec 13, 2017 @ 15:13:55

Robert Basic has a new post to his site where he shows how to use the Mockery unit testing too to return different values for different arguments. Fortunately there's something already built into the tool to help handle this.

Sometimes when working with Mockery mock objects, we want to tell a mocked method to return different values for different arguments. It is a rare occasion when I need this feature, but every time I need it, I’m happy it’s there.

The feature that allows us to return different values based on arguments is the andReturnUsing Mockery method, which takes a closure as an argument.

He includes examples of the use of this andReturnUsing method in mocks and showing that there's more than one way to accomplish the same kind of goal. While this is a useful method to use when needed he points out that refactoring the code under test is probably a better way to go instead.

tagged: mockery unittest arguments return value tutorial

Link: https://robertbasic.com/blog/mockery-return-values-based-on-arguments/

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