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

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.

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.

On thePHP.cc blog today there's a new post sharing some helpful hints related to refactoring your application to PHP 7 written up by a friend of the group, Tim Bezhashvyly.

Recently I have migrated a relatively large codebase from PHP 5.6 to PHP 7 and would like to share some of my learnings. To get the most out of this article, you should be familiar with scalar type declarations (and return type declarations). To learn about these and other features of PHP 7, I recommend the "PHP 7 Explained" eBook.

He makes the recommendation of a bold first step: enabling the strict typing on every file in your application to enforce the typing of all values. Next he recommends running your current test suite to see where the failures are. Changes are pretty high that you'll find issues with type switching and magic method handling. He suggests a method for migrating your code effectively to PHP 7: a test-driven migration. This focus works fine if your coverage is good but unless you're exercising all parts of your codebase things will unfortunately be missed.

He also points out some other changes you can make with this update including the removal of some PHPDoc annotations (you'll know the type for sure now) and modifications that may need to be made to current mock objects in your tests. There's a few other smaller things he recommends looking out for as well including the use of the "silencer" operator and exception changes.

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.

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.

On the DotDev.co site a tutorial has been posted showing the full set up of an API using Laravel, Dingo and JWT tokens while following test-driven development principles along the way.

As the complexity of API’s increase, improving the ways we create them becomes a necessity. Let’s take a journey exploring an efficient way of building well-tested API’s that are easy to develop and maintain by wiring up several different open-source packages.

In this tutorial, we will build a very simple API for fruits that lists all the fruits, shows one fruit, creates a fruit, and finally deletes a fruit. The API will allow anyone to list and show fruits but we will use JWT Authentication to protect creating and deleting operations so only the registered users can use them.

The tutorial starts by helping you get the TDD environment set up for the application and the required libraries installed. From there they install and configure Dingo and look at the role that transformers play in the API output. With a basic API in place the JWT tokens are integrated and another package is used to generate simple, clean API documentation. Full links to other packages, screenshots of the expected output and all the code you'll need is included.

On the SitePoint PHP blog they've continued their series covering the SparkPost mail delivery service and integrating it in to your application. In this latest part of the series author Christopher Pitt starts looking at the SparkPost API and uses it as a chance to practice some TDD (Test Driven Development) skills.

In a previous post, we looked at SparkPost (as an alternative to Mandrill), and explored a bit of the official PHP client. The official client handles a decent amount of work, but I got to thinking about what it would take to build a new client.

The more I thought about it, the more it made sense. I could learn about the SparkPost API, and practice Test Driven Development at the same time. So, in this post we’ll look to do just that!

He uses a few different libraries to explore the API and its endpoints: Guzzle for the HTTP requests and the Mockery+PHPUnit combination for the testing. He includes the setup and configuration for the testing environment and some sample tests for making sure things are connected. He then integrates Mockery into the testing, using it to mock the Guzzle requests and still have the tests pass even without the actual connection. He then works through several other tests and finishes the post with a mention of building coverage results for the "Client" class.

The SitePoint PHP blog has an article posted by Vitalij Mik showing you how to merge the concepts of "clean code architecture" and test-driven development to make solid, maintainable code. The ideals of the "clean code architecture" were first proposed by Robert C. Martin in this post on the 8thlight blog.

The idea was to create an architecture which is independent of any external agency. Your business logic should not be coupled to a framework, a database, or to the web itself. [...] Frameworks will continue to change and evolve. With composer, it is easy to install and replace packages, but it is also easy to abandon a package (composer even has the option to mark a package as abandoned), so it is easy to make “the wrong choice”.

In this tutorial, I will show you how we can implement the Clean Code Architecture in PHP, in order to be in control of our own logic, without being dependent on external providers, but while still using them. We will create a simple guestbook application.

He starts with a first test, evaluating that a list of entries for the guestbook is empty. The code shows the "fakes" for the different object types Uncle Bob recommended in his article and how it fails because none of them exist yet. He extends this with a "can see entries" test and then starts in on the "use case" class to start making the test pass. He updates the case to pull in entries from the repository, another external dependency created later in the tutorial. He then goes through creating the classes for the "fakes" in the test and refactoring the test based on some of his changes during their development. In the remainder of the post he talks about the independence of the current setup and how to add in pagination functionality on the entries objects.