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.

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.

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.

The SitePoint PHP blog has posted the third part of their series guiding you through the creation of your first PHP package with a look at mocking API responses in unit tests created via the TDD (test-driven development) process.

In parts one and two, we built some very basic functionality and used TDD with PHPUnit to make sure our classes are well tested. We also learned how to test an abstract class in order to make sure its concrete methods worked. Now, let’s continue building our library.

He starts with a bit of catching up to ensure everyone is on the same page in the development process. From there he starts in on the mocking of the API, preventing the need for the (slow) external requests. He shows some updates that are needed to the main DiffBot class, the factories/entities for making objects for requests and examples of putting these to use in a few tests. Finally he shows the creation of the mocks themselves and the result from a sample test.

In his latest post Mathias Verraes poses the question of how much testing is too much? At what point does testing actually become less useful and how much you really need.

Figuring out how much unit tests you need to write, can be tricky, especially if you are new to Test-Driven Development. Some teams strive for 100% code coverage. Some open source projects even announce their test coverage on their GitHub profiles – as if coverage is an indicator of quality. Coverage only measures the lines of code that are executed by the test suite. It doesn’t tell you whether the outcome of the execution is actually tested, let alone how valuable that test is. Because of that, code coverage of your entire code base is a pretty lousy metric.

He suggests that the "it depends" answer to "how much testing is enough" question just isn't good enough. He puts most of this in the context of TDD (where testing is built-in to the development time) but some of the thoughts could apply to post-code testing as well. He also talks about over-design and how it relates to refactoring with deeper insight. Finally, he talks about a subject not mentioned much in testing articles - when to delete tests.

In this latest post to the Inviqa blog they ask the question "how clean is your code?" and offer a few tips to help it get that way (and stay that way).

During the Test Driven Development training (which includes Behat, and PHPspec) run by Marcello Duarte, I was particularly blown away by one of his many and funny analogies… “Would you have any surgery carried out by a doctor who does not wash his hands?” Everybody in the room shook their heads. Of course nobody would. There is too a high risk of complications. In software development ‘infected’ code can translate to bugs, bad user experience, poor performance and the complete failure of web applications.

He talks briefly about some of the lessons learned in this training session, pointing out that while it's not the easiest method to apply, it pays off in the long run of your code's "hygiene". He points out that the [Inviqa] group's success rate with TDD/BDD has reflected in the bottom line of their enterprise clients too.

Dave Marshall has shared his method behind using test-driven development in his recent development.

I’ve been watching the Destroy All Software back catalog over the last couple of months and it’s really inspired me to up my TDD game. I’m still fairly new to TDD, I’ve written tests for a long time, but never really let it lead my development…

He talks about the testing tool he uses and some of the ideals he keeps in mind when developing his tests. He also comments on testing isolation, speed of execution, the "fail fast" idea as well as integration testing and continuous integration.

Freek Lijten has a new post to his blog - a review of a book (from Freeman & Price) called "Growing Object-Oriented Software Guided by Tests". It's based on Java, but the ideas presented can be applied pretty universally.

It may seem strange but I'd like to start out with giving my opinion on this book: It is brilliant! If you don't like reading my post you at least know what you should do next: buy the friggin' book. The book offers some theory concerning agile development, (unit-)testing and code quality but its killer feature is the almost 200 page long example of developing an application the TDD way! In the rest of this post I will shortly highlight different parts of the books and stuff I enjoyed or learned from it.

He breaks up the review in to a few different parts - the process of test-driven development, his "first real lesson", their working example and a section about the more advanced topic of sustainable test driven development.