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.

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.

Matt Sparks has posted the latest tutorial in his "Building a PHP framework" series of posts. In this latest article he covers the use of test-driven development during the development of some of the first framework code.

In part 4 we laid the foundation for Analyze. Now it’s time to write the very first lines of code! [...] Essentially, test driven development is a process of writing tests before writing any code, then writing code that passes the tests. [...] If you’re new to TDD, this probably seems pretty weird. Stick with me.

He starts with a brief definition of what test-driven development (TDD) is and what tool he'll be using to create the tests. Next is a simple example of a test that creates a class instance (NumberAdder) and calls an add method on it. This fails because none of this exists yet, hence the "test first" part of TDD. He then goes back and creates the class and method and loads them so the test can use them.

On his Medium.com site Peter Lafferty shares a method he uses for test-driven development on Silex controllers, something made difficult by the way the dependencies are injected into the controllers automatically.

“TDD it’s so easy” that’s what they tell us. There’s not trick to it, it’s just a simple trick. This article shows one way to unit test Silex controllers.

The way to implement TDD on a Silex controller is composition, low coupling and dependency injection. At its most basic a Silex controller has no relationship to Silex. However its easy to end up with controllers tightly coupled to the Application and Request classes.

He talks about the two main issues around effective TDD with Silex: the way the dependency injection controller is injected automatically and how the controller "resolver" enforces certain method names. He's figured out tricks to help get around these issues, though. The first involves creating the controller as a service and the second is to only pass the parts of the request the method needs. He includes code showing this in action to help clarify his points.

The SitePoint PHP blog has posted a tutorial that re-introduces PHPUnit and TDD (Test-Driven Development) showing you how to get started with this pre-code testing process if you want to integrate it into your development.

There are a lot of PHPUnit posts on our site already (just check the tag), but it’s been a while since we’ve actually introduced people to it, and the tool has evolved significantly since then.

This article aims to re-introduce the tool in a modern way, to a modern audience, in a modern PHP environment – if you’re unfamiliar with PHPUnit or testing, this post is for you.

They assume you're already familiar with PHPUnit and have an environment already set up with PHP and PHPUnit. They start by briefly introducing Test-Driven Development and the PHPUnit for those not overly familiar with the basics. They then bootstrap a sample application using the PDS-Skeleton project. The tutorial then walks you through the setup of the testing environment, Composer configuration and the creation of your first test. With all of that in place they start in with some failing tests (remember, TDD is "test first") and then writing the code to make it pass. They add more tests and use a data provider to set up different cases and run them all through the same test. The post then looks at code coverage reports and the results showing how much of the code is covered by tests.

On the SitePoint PHP blog they've continued their series looking at upgrading Sylius, an e-commerce application based on Symfony, with the help of test-driven development methods to ensure nothing breaks along the way. These next two articles cover the use of PhpSpec and using Behat for the different types of testing.

Last time, we developed some new features on top of Sylius’ core to indicate which products and their variants are low on stock and need replenishing. Now, we move on to seeing our changes in the UI, which means we will need to do a bit of StoryBDD testing.

In [the third] part, [we] extend some core classes to indicate color-coded inventory status. First, we’ll deal with the back end part. In a followup post, we’ll use Behat and test the visual changes. Please follow the instructions in the previous post to get a working instance up and running.

In each of the tutorials they walk you through the changes you'll need to make on the Sylius side to test both the Inventory and Product functionality that already come with the package. Examples of each kind of test are included as well as the output from the example test runs.

Jason McCreary has a post on his site where he's officially accepted a challenge made by Adam Wathan during the Laracon Online conference and how he went about solving it.

Last week at Laracon Online Adam Wathan gave a talk entitled “Lies you’ve been told about testing”. Following the talk, Adam posted a challenge. Amid Adam’s post, he makes a single claim and presents a challenge.

The challenge was to write a unit test for the three provided class implementations in isolation. The claim is that isolated unit testing is incompatible with Test Driven Development (TDD). He talks about the other phases of TDD outside of the "refactor" step ("red" and "green") and how he would apply those to the steps leading to a complete refactor. He also talks briefly about testing styles and what would need to change to complete the process on both the code and the test side.

The Laravel News site has posted a review of "Test Driven Laravel", a course from Adam Wathan walking you through the creation of a Laravel-based application from a completely Test-Driven Development approach.

I’ve been programming for close to a decade, and I’m constantly trying to find ways so to improve my skill set to be able to keep up with the ever-changing landscape of technology. The one area I’ve always wanted to improve in has been testing. [...] When Adam announced at Laracon that he was creating a course on building real-world applications with TDD, I was really excited to see where it would go.

Over the past couple of months, I’ve been lucky enough to preview the course as the lessons get finished. It’s been really helpful because I’ve been working on a large, complex application, and I’ve been able to apply the things I’m learning immediately in my day-to-day work.

The review goes on to talk about some of the things they've learned already from the course including test coverage for parts of the app that work with 3rd party services. They link to this talk from Adam as an example of some of the concepts taught in the course and, of course, a link where you can purchase your own Early Access pass and start learning.

On the Tighten.co blog they have a recent post sharing a better dd() for your TDD - basically a better method for debugging the current state of object with a "dump and die" function.

An important part of every Laravel developer's debugging arsenal is the humble dd() helper function—"dump and die"—to output the contents of a variable and terminate execution of your code. In the browser, dd() results in a structured, easy-to-read tree, complete with little arrow buttons that can be clicked to expand or hide children of nested structures. In the terminal, however, it's a different story.

[...] Fortunately, it's simple to build your very own customized version of dd() to help tame your unwieldy terminal output—helping you find the details you're interested in quickly, without wearing out your trackpad (and your patience).

He provides two options you can use to help clean up the output of a "dump or die" method from the extensive results the current "dd" function provides:

• Option 1: Using Symfony's VarDumper (with custom configuration options)
• Option 2: Kint

Kint provides a few other helper methods you can use and easily configurable max and min depth to show in the output.

While his examples may be in Javascript, Jani Hartikainen has posted a guide that can help any developer get started with TDD - Test Driven Development - in their new or legacy applications.

What’s the hardest thing in test-driven development or unit testing in general? Writing tests! The syntax or the tools aren’t the problem – you can learn those enough to get started in 15 minutes. The problem is how to take some vague idea in your head about what you want to do, and turn it into something that verifies some function works… before you even wrote the damn thing!

People tell you to use TDD. But how can you possibly write a test for something that doesn’t exist? I don’t even know what the function is going to do yet – or if I actually want two functions instead of one – and instead you want me to think of a test for it? Are you crazy?

How do all those people who tell you to use TDD do it? That’s the thing – test-driven development requires thinking of your code in a different way. And nobody ever tells you how to do that. Until now.

He then breaks down the process of how to turn a "vague idea" into something that can be effectively tested, noting that this change in thought process can sometimes be difficult. He then breaks it down into a set of five steps:

• Step 1: Decide the inputs and outputs
• Step 2: Choose function signature
• Step 3: Decide on one tiny aspect of the functionality
• Step 4: Implement test
• Step 5: Implement code

While the above may seem familiar to anyone that's read about TDD before, it's interesting to see how he explains each item with an emphasis on behavior not just the code required. He ends the post with a few more smaller suggestions to help you get on the road to TDD with the same emphasis on behavior rather than functionality.