On the Laravel News site Tim MacDonald has written up a post sharing some tips on how you can speed up your PHPUnit tests, making them easier to run and more useful during the development process.

Having a fast test suite can be just as important as having a fast application. As a developer, getting feedback quickly about the state of your code allows for a much quicker development turnaround. Here we are going to run through some tips you can implement today to make your tests run faster.

The example test suites have been made intentionally slow to simulate a broader set of tests and also to emphasize the improvements possible. Your real-world mileage may vary.

He makes recommendations around the use of ParaTest to run the tests in parallel, re-running only failed tests, grouping slow tests, lowering the password hash "rounds" count and disabling XDebug. Each item in the list includes instructions on what changes need to be made and screenshots of the results of the change.

In a recent post to his site Freek Van der Herten talks about "handcrafting mocks" in your unit testing. In his example he shows the creation of custom mocks rather than using one of the current mocking test tools.

In an application I was working on I wanted to implement automated tweets. Of course, this logic should also be tested. In this blogpost I'd like to show you how you can easily handcraft your own mocks.

In his application, he wanted to be able to send tweets to Twitter when certain events happened. He starts with a bit of set up showing how to use this library to set up the OAuth connection between your application and Twitter account. He then shows the class that will make the actual tweet and how to use event handling to send the message when a new blog post is published. With this all in place, he starts in on the testing, showing the creation of the custom mock (so tweets aren't actually sent) and how to use it to test that a tweet was sent. He finishes the post with a mention of a possible refactoring: using an interface instead of extending a class to make the testing more structured.

Rob Allen has a new post to his site sharing a method you can use in your testing to replace a built-in PHP function with something customized for your needs.

Recently I needed to test part of Slim that uses the built-in PHP functions header() and headers_sent(). To do this, I took advantage of PHP’s namespace resolution rules where it will find a function within the same namespace first before finding one with the same name in the global namespace. The idea of how to do this came courtesy of Matthew Weier O’Phinney where this approach is used for similar testing in Zend-Diactoros.

He starts off with the code he wants to test - a response method - and a simplified version of the test. This method makes use of the headers_sent and header functions in PHP but those needed to be overridden in order to make the test actually work. He includes the changes to make to the test to override these methods because of how namespaces resolve (using the global PHP namespace last).

In a new post to his site Frederick Vanbrabant tackles the integration operation segregation principle. While the term sounds intimidating, it's just a long way to say something you probably already do: refactor code into smaller testable chunks.

A few weeks ago I attended a DDDBelgium meetup where I was lucky to participate in a refactor workshop lead by Pim and Joop. After the incredible workshop Pim, Dries and me were discussing some code that we refactored earlier . Not so long in the conversation the words “Integration Operation Segregation Principle” casually got dropped by Pim.

Now I’m going, to be honest with you (as I was with them), I had no idea what the hell he was talking about. And maybe neither do you.

He starts with some simple code for a "calculator" class with a calculate method to handle the pricing of a rental car. He includes the test for the class/method as well, using a mock object and several expects calls to handle the method calls. The test ends up being larger than is probably good, so he looks into refactoring the original code to abstract out some of the functionality and make it more testable. In the process this also makes the code easier to follow and, while there is more of it, more maintainable and flexible in the end.

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.

Matt Glaman has a tutorial posted to his site sharing some of his experiences in using PhpStorm and its auto-testing feature when working with his codebase following a test-driven development approach.

When I work, I try to follow the principles of Test-Driven Development. I have found it to aid me in writing cleaner code, identifying odd coupling of components or crazy accidental dependencies between components. It also lets me write my API first by using mocks against interfaces I have defined.

[...] One of the key aspects of TDD to is to write your test and assert expectations, and then write code. That means you will be running your tests — a lot. That means having to manually run your tests for each code change (as you should) will kill your velocity. That’s where PhpStorm’s auto-test functionality comes in.

He includes a bit more detail about the feature including a screenshot) and a screencast video of it in action.

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.

On the CloudWays blog there's a tutorial posted for the CodeIgniter framework users out there showing how to get started with unit testing your application.

Quality assurance is one of the central aspects of software development. In fact, test-driven development is an entire development methodology developed around the concept of integrating quality assurance within the development cycle. However, before discussing how to automate Codeigniter unit testing, I will describe the theoretical basis of unit testing and how it adds value to the Codeigniter projects.

The tutorial starts out by defining what a "unit" is and how testing provides value to your project, making it easier to find issues early on and building in simplicity in its structure. It also talks about some of the limitations of unit testing including the effort involved (and lack or potential gain) and having test code with bugs too. It then starts in on some example tests, showing how to work with configuration objects and built test cases and execute the tests.

On his HackerNoon site Sameer Nyaupane has posted part four of his series covering test-driven development in PHP. In this latest post he covers the use of mocking.

Hey there, welcome to part 4! Today we’ll learn how to mock. Mocking is a process where you create a fake instance of a real class, and test against it. This is so that, you do not have to worry about the real functionality of external dependencies inside a class. This makes unit testing a lot easier and reliable.

[...] Although PHPUnit does have mocking capabilities, it is not as full fledged as that of Mockery’s. We’ll be using Mockery for all our mocking needs.

He starts with some sample code, a simple Math class that calculates the area of a square (but doesn't implement it fully). This includes the need for an instance of a Calculate class that doesn't exist yet. He then works up a test for the Math class, mocking the Calculate class and calling the getArea method to evaluate the result. He walks you through each line of the code, sharing what's happening during test execution.

Larry Garfield has written up a post with a somewhat controversial headline, especially for anyone that's done any kind of unit testing on a larger codebase. His suggestion is to no use mocking libraries and some other techniques that can replace them.

I am all for testing. [...] There's a lot of opinions on what constitutes a "good" test, of course, and much is subjective to the type of code you're working on. However, since the release of PHP 7 I've found that while writing tests... I am never using a mocking library. In fact, I'm going to go as far and say that you should never use a mocking library in PHP 7.

Before all of you gasp, clutch your pearls, and send ninja hit squads after me, let me justify that position.

He starts off by defining what a "mock" is a more general sense and then, more specifically, how mocking libraries are mostly implemented in PHP. He covers the DSL (domain specific language) knowledge that's required to use most of them and how something already included in PHP 7 - anonymous classes - could be a viable alternative. He goes on to show examples of using this method rather than a mock for simple object handling and even recommends making an actual class (just for testing) if the need is there. He ends the post talking about the "upper bounds" of when this might not be as useful and how this can actually be good (using it as an indicator that you need to refactor the main code to simplify).