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.

On the Delicious Brains site, there's a tutorial posted asking WordPress plugin developers if their code is ready to work with Gutenberg, the next major release of the editor used in the popular blogging tool and content management system.

WordPress 5.0 is right around the corner with the flagship feature, the new Gutenberg editor, set to change the WordPress landscape dramatically. Gutenberg not only impacts how you write content in WordPress, but how developers build plugins for WordPress.

[...] In this post I’ll walk you through the process I took for making Intagrate, my Instagram WordPress plugin, Gutenberg-compatible, which will hopefully get you started on making your own plugins Gutenberg-ready.

The post starts with some general things to consider about Gutenberg's functionality as compared to the classic editor and some key places to check in your own plugins. They then provide a guide to testing your plugin by installing the standalone editor package. It then walks through the three main places to check functionality:

• custom post types
• custom meta boxes
• TinyMCE

The post ends with some suggestions of possible enhancements such as making use of shortcodes and converting custom meta boxes.

Sameer Nyaupane has posted the latest part in his "PHP Test Driven Development" series of tutorials. In this latest post, part five, he focuses on integration testing, ensuring the components are all working together as they should.

Let’s learn about Integration testing today. Integration testing is a method of testing by passing in the real dependencies and thus testing out the integration between two or more objects.

He updates the examples from his previous post to test the integration between the Math and Calculate classes. He walks you through the changes required to the phpunit.xml configuration and the creation of the initial test classes. He goes through each line of the tests, explaining what it's doing and how mocks are used to help with dependencies.

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).

On the TechBeacon site they've posted an article about choosing the right testing tools for your codebase and why making the right choice matters.

Fast end-to-end tests are the next big thing. The tooling has improved tremendously, and the productivity and insight gains are too good to ignore. Modern tools such as Cypress and >TestCafe are becoming quite impressive and can give you confidence in your product's quality.

As with most facets of software development, there is a balance to be strived for between speed and test confidence. The leverage point depends on the project, and the two most common types of software project these days are web services and enterprise software.

They talk about some of the differences between the testing of web services versus enterprise software as well as some of the practical advantage of fast tests. They also cover the advantages of broad tests and cover some of the current tools for testing including Cypress.io and Laravel Dusk.

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.

Marcel Pociot has a recent post to his site showing how you can set up builds on the Travis-CI service for your Laravel Nova packages. Laravel Nova is the recently released product from the Laravel creators that provides an administrative dashboard.

Today Laravel announced that Laravel Nova can now be installed via composer. This works by providing your nova.laravel.com username and password as credentials for composer, as well as adding a custom Laravel Nova composer repository to your composer.json file.

[...] This is great news, as this does not only simplify updating Laravel Nova, but it also allows Nova tools/package developers to add continuous integration to their projects! But there is still a problem: we do not want to provide our Laravel Nova credentials in our open source repository. But how can we solve this?

Marcel then walks you through the process of using Travis-CI's encrypted environment variables to protect your credentials. He shows how to install the travis Ruby gem to get the travis command line tool, encrypt the values and update your Travis-CI configuration (.travis.yaml) to pull those into the build.

Earlier this month, the Symfony blog made an announcement about a new browser testing and web scraping tool that's been released under the Symfony umbrella: Panther.

Since the very first version of Symfony 2, the framework provides a suite of convenient tools to create functional tests. They use the BrowserKit and DomCrawler components to simulate a web browser with a developer-friendly API.

The post starts with a "refresh" of the current WebTestCase helper functionality to create these functional tests. They also include an example of a repository class that stores/retrieves the news and a matching controller to handle the requests (and Twig templates for output). They then create a test using the WebTestCase functionality to get the index and ensure that some of the content is correct.

The tutorial then takes this same scenario and applies tests using the new Panther functionality. Where the WebTestCase uses a simulated browser internal to the framework, Panther uses an actual browser to run is tests using the Facebook PHP WebDriver library. They show the slight updates that would need to be made to the current test and the resulting output.

The tutorial goes on to provide other examples of tests for API requests and Javascript functionality for a Vue.js frontend. It wraps up mentioning some of the additional functionality Panther includes such as the ability to take screenshots and injecting Javascript into the pre-rendered page.

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).

Matthias Noback has posted another article covering domain-driven development practices, this time focusing on testing actual behavior and some of the downsides that can come with it and domain-driven development.

He breaks the article up into three main sections:

• The downsides of starting with the domain model
• The downsides of starting with the smallest bricks
• The downsides of your test suite as the major client of your production code

Each includes a description of the downsides related to the topic and, where it helps, code to illustrate the issue. The post also includes three experiments to try to help prevent some of these downfalls from happening (including not testing constructors and not adding getters).

Tests are not the main use case of an object, they should guide the development process and make sure you write exactly the code that you need. This means not sacrificing the object's encapsulation just to make it testable.