Matt Glaman has a new post to his site where he walks you through the setup and execution of Drupal's unit tests in the DDEV platform (a Docker-based project that makes it easy to get an environment up quickly).

DDEV is a local development stack built on top of Docker. It gives you all of your environment needs without messy configured on your host machine, without needing to know Docker or configure your own containers. Which is great, and makes life easier. Instead of just using DDEV to develop your site or application locally, why not also run your tests within it?

I have had quite a few people ask me how I configure my setup for testing with Drupal’s PHPUnit test suites. [...] All of these are the same reasons for using a virtual machine or containerized local development stack. So, it is fitting we run our tests within these local stacks as well!

In this article, part one of three, he assumes you already have a DDEV environment up and running with a Drupal application running inside (there's a guide here). With that in place, he shows how to configure PHPUnit via the phpunit.xml file, changing the "SIMPLETEST_*" values for the localhost and local DB connections. He shows how to run the tests by SSHing into the web Docker container and pointing PHPUnit at the configuration file. The end result should look something like this in a terminal.

Jessica Mauerhan has a tutorial posted to her site that covers the five types of test doubles in PHPUnit and how to use them in your tests. Test "doubles" - the most common one being a mock - are useful for simulating resources or other objects required to test units of code without external interactions.

Did you know that a Mock is only one type of a test double? Most of us use the word “mock” to mean any kind of test double, but there’s actually five different types. It really can help you understand what you’re trying to accomplish with your test if you know a little bit more what you’re doing with your test doubles, so this article will explain the kinds of test doubles, when you use them, how you use them and why.

She starts the post with a brief definition of the term "test double" and then covers each of the five with descriptions and example code:

• Dummy
• Stub
• Spy
• Mock
• Fake

While some of the functionality is similar between the types, she defines their differences and the cases where each would be most useful.

Matthias Noback has continued his series of tutorials covering various uses of the Repository design pattern. This is the second part of the series and picks up where part one left of, showing the handling of entities in the repository, performing the usual CRUD operations.

In part 1 of this short series (it's going to end with this article) we covered how you can test-drive the queries in a repository class. Returning query results is only part of the job of a repository though. The other part is to store objects (entities), retrieve them using something like a save() and a getById() method, and possibly delete them. Some people will implement these two jobs in one repository class, some like to use two or even many repositories for this. When you have a separate write and read model (CQRS), the read model repositories will have the querying functionality (e.g. find me all the active products), the write model repositories will have the store/retrieve/delete functionality.

In particular if you write your own mapping code (like I've been doing a lot recently), you need to write some extra tests to verify that the persistence-related activities of your repository function correctly.

He starts with the test cases for the functionality (following the test-drive design mentality) and talks about the expected behavior of the various entity and repository methods. He includes the code for these tests covering state changes, handling child entities, deleting entities, and working with ports/adapters.

Continuing the theme of posts related to using PHP on the OpenWhisk serverless platform, Rob Allen has posted a few notes for working with the PHP runtime.

These are some notes for working on the OpenWhisk PHP Runtime, but are probably applicable to the other runtimes too.

His notes cover:

• some basic setup
• building the two containers (PHP 7.1 and 7.2)
• running tests
• using the container interactively
• checking the format of Scala files

Commands are included for each item along with some of the output to expect.

In a new post to his site Tomas Votruba shows you how to make your unit test mocks better with an easier and clearer way to use them. This simplification makes use of something PHP itself is already able to do: create anonymous classes.

At the time being, there is only 1 post about anonymous classes in tests (thanks to Matthieu!). Compared to that, there are many PHP tool made just for mocking: Prophecy, Mockery, PHPUnit native mocks, Mockista and so on. If you're a developer who uses one of them, knows that he needs to add proper annotations to make autocomplete work, has the PHPStom plugin that fixes bugs in this autocomplete and it works well for you, just stop reading.

This post is for developers who struggle with mocking and have a feeling, that they're doing something wrong.

He starts with an example of a test that creates a mock for an external request to the Heroku service using PHPUnit's mocking tools. He points out that this requires extra knowledge of the mocking methods and functionality to accomplish, potentially making it difficult to understand for those new to the tool. He then shares a refactor of the same test, this time making use of an anonymous class to mock out the needed findByCategoryId method and return a response. He ends the post pointing out that, as a side effect of this refactoring (and other interface refactoring) you'll create more SOLID code and it can help make it easier to maintain in the future.

Tomas Vortuba has a tutorial posted to his site showing you how to test private services in Symfony in unit tests for pre-4.1 Symfony installations (it has been resolved via simpler testing methods in Symfony 4.1 with the FrameworkBundle).

2 versions of Symfony are affected by this dissonance between services and tests. Do you use Symfony 3.4 or 4.0? Do you want to test your services, but struggle to get them in a clean way?

Today we look at possible solutions.

He starts with an example of the error you'd face if you tried to pull a service directly from the container that was marked as private. While you can specifically make it public in the yaml configuration, this potentially means doing that for all of the services you need to test. While this might work for smaller projects, it's unmaintainable for larger ones. He then shares some other options that could help resolve the issue including the one he ended up on: a compiler pass. He gets into a bit of detail on the changes this would require and where the "magic" is that lets it work.

In a post to his Medium.com site TJ Miller has a quick post for the PHPUnit users out there showing how to isolate your tests and prevent them from interacting by splitting them into different test suites.

On a recent Full Stack Radio episode Adam Wathan and Taylor Otwell were talking about testing Laravel applications. During the episode, they spoke about isolating interactive integration tests from your normal testing e.g. payment gateways, third-party integrations.

TJ shares an example of a project he's working on where this is useful: avoiding interactions with an HTTP API every time the tests run. He then shows how, with a single PHPUnit configuration, you can split up the tests by name and directory to prevent them all from executing every time. Then the "testsuite" option can be used to isolate the execution from the command-line. An example of the XML configuration is also included in the post.

Frank de Jonge has a new post to his site covering something that always seems to be a difficult topic in development: time. In his post he suggests that date and time handling in your application is a "dependency" that could be difficult test.

When developers talk about the infrastructural boundaries or external dependencies they often talk about databases and third-party integration. They're the first thing we'll put behind an interface so we can stub them out during our tests. This gives us some control over them. It's become relatively easy to spot these dependencies because we do it frequently. They're the usual suspects.

However, some "dependencies" are much harder to spot. They even live right inside the standard library of PHP and often manage to seep through the cracks. Date/Time handling is such a thing. So what's the problem and how do we fix it?

He goes on to talk about date/time handling programming languages in general and how its variance can can cause issues that might be out of our control. He suggests that when time "gets the best of you" you should opt to be more specific in your date/time handling (the cause is usually precision). He then gets into some code examples of how to "control time" by reducing the impact that direct date/time handling could have on your application. He also includes an example of testing this handling and finishes with the idea of "consuming time as a service".

For those out there that are new to using the Laravel framework and are a bit lost in trying to figure out its structure, Laravel News has just the article for you. In this new tutorial they give you an overview of the Laravel codebase and how you should structure your applications to keep everything organized.

Getting started in a new codebase can be very overwhelming, even more so if you are new to programming. So where do you start? Where are the places to look to learn the most about a codebase? Let’s take a look at few common areas for Laravel.

They start by talking about project documentation and how it can play a vital role in the on-boarding of developers new to the application. From there the post goes on to talk about the composer.json configuration, route configurations, service providers, tests and some additional tooling. For each item there's a paragraph or two explaining its place in a Laravel application and, in some cases, links to other resources for more information.

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.