Posts tagged with testing

Expressive Code & Real Time Facades

In a new post on his blog Taylor Otwell gives a nice example on how real time facades can make code more testable.

Recently, I worked on some code that surfaced my most common use-case for Laravel 5.4’s “real-time” facades. If you’re not familiar with this feature, it allows you to use any of your application’s classes as a Laravel “facade” on-demand by prefixingFacades to the namespace when importing the class. This is not a feature that is littered throughout my code, but I find it occasionally provides a clean, testable approach to writing expressive object APIs.

https://medium.com/@taylorotwell/expressive-code-real-time-facades-41c442914291

Read more

A practical introduction to snapshot testing

While working a little bit on laravel-sitemap I decided to refactor the tests to make use of our own snapshot assertions package. The snapshot package enables you to generate snapshots with the output of your tests. On subsequent runs of those tests it can assert if the output still matches the contents of the snapshot.

In this video I demonstrate how the refactor of the tests of laravel-sitemap was done. (double-click on it to view it full-screen)

If you want to know more about snapshot testing, then read this blog post written by my colleague Sebastian. The refactor of the tests can be viewed in this commit on GitHub.

(Little note on the video itself: this is my first tutorial video I ever made. After recording it I noticed that I used a wrong ratio resulting in those black bars on the side. Ah well, you live you learn. Next time it will be better. For those interested, I used a Blue Yeti Pro mic to record my voice and ScreenFlow to record and edit the video.)

Read more

Join thousands of developers

Every two weeks, I share practical tips, tutorials, and behind-the-scenes insights from maintaining 300+ open source packages.

No spam. Unsubscribe anytime. You can also follow me on X.

A package for snapshot testing in PHPUnit

My colleague Sebastian recently released a new package called phpunit-snapshot-assertions. In a new post on his blog he tells all about it.

The gist of snapshot testing is asserting that a set of data hasn’t changed compared to a previous version, which is a snapshot of the data, to prevent regressions. The difference between a classic assertEquals and an assertMatchesSnapshot is that you don't write the expectation yourself when snapshot testing. When a snapshot assertion happens for the first time, it creates a snapshot file with the actual output, and marks the test as incomplete. Every subsequent run will compare the output with the existing snapshot file to check for regressions.

https://medium.com/@sebdedeyne/a-package-for-snapshot-testing-in-phpunit-2e4558c07fe3

Read more

Working With PHPUnit and PhpStorm

On the JetBrains blog Gary Hockin explains how to easily run a single PHPUnit test.

To run all the tests in a single file, right-click the test in the Project Pane (the left-hand navigation pane), and select Run .

To run all the tests in a single class, right-click the class name in the editor, and select Run .

To run the tests in a single method, right-click the method name, and select Run .

https://blog.jetbrains.com/phpstorm/2017/01/working-with-phpunit-and-phpstorm/

Read more

An artisan command to easily test mailables

Most of the Laravel apps we create at Spatie will send mails. This can be a password reset mail, a welcome mail after registration, an order confirmation mail, ... One of the things we do is styling such mails so it has the same look and feel as the site it was sent from. When testing such mails our designers had to request a password reset or go through the entire checkout flow just to receive such an order confirmation mail. To make that testing process a lot easier we've created a package called laravel-mailable-test. This package provides an artisan command that can send a mailable to an mail-address.

To send any mailable issue this artisan command:

php artisan mail:send-test "App\Mail\MyMailable" recipient@mail.com

This will send the given mailable to the given email address. The to-, cc- and bcc-addresses that may be set in the given mailable will be cleared. The mail will only be sent to the email address given in the artisan command.

The package will provide a value for any typehinted argument of the constructor of the mailable. If an argument is a int, string or bool the package will generated a value using Faker. Any argument that typehints an Eloquent model will receive the first record of that model.

Image the constructor of your mailable looks like this:

public function __construct(string $title, Order $order) 
{
   ...
}

That constructor will receive a string generated by the sentence method of Faker and the first Order in your database.

The values that are passed to the constructor of the mailable can be customized using the values option of the command.

php artisan mail:send-test "App\Mail\MyMailable" recipient@mail.com --values="title:My title,order:5"

Using this command My title will be passed to $title and an Order with id 5 will be passed to $order.

To learn more about the package head over to the readme on GitHub. Be sure take also take a look at this list of Laravel packages our team has previously made.

Read more

The Magic Tricks of Testing

In a mail sent to all subscribers on the testdrivenlaravel.com-mailinglist Adam Wathan mentioned a talk Sandi Metz gave a couple of years ago at Rails Conf. It's a really good talk that explains in a clear way when and what you should test.

Tests are supposed to save us money. How is it, then, that many times they become millstones around our necks, gradually morphing into fragile, breakable things that raise the cost of change? We write too many tests and we test the wrong kinds of things. This talk strips away the veil and offers simple, practical guidelines for choosing what to test and how to test it. Finding the right testing balance isn't magic, it's a magic trick; come and learn the secret of writing stable tests that protect your application at the lowest possible cost.

Read more

An uptime and ssl certificate monitor written in PHP

by Freek Van der Herten – 9 minute read

Today we released our newest package: spatie/laravel-uptime-monitor. It's a powerful, easy to configure uptime monitor. It's written in PHP and distributed as a Laravel package. It will notify you when your site is down (and when it comes back up). You can also be notified a few days before an SSL…

Read more

Testing interactive Artisan commands

For a new package I'm working on I had to test some Artisan commands. The commands I want to test contain calls to ask and confirm to interactively get some input by the user. I had a little trouble finding a way to tests such commands, but luckily a blogpost by Mohammed Said pointed me in the right direction, which was to leverage partial mocks.

Here's the most interesting part, Artisan Commands can ask the user to provided specific pieces of information using a predefined methods that cover all the use cases an application might need. ... So we mock the command, register the mocked version in Kernel, add our expectations for method calls, and pretend the user response in the form of return values. ...

http://themsaid.com/building-testing-interactive-console-20160409/

Read more

Preventing API drift with contract tests

In an older post on his blog Adam Wathan shared an interesting approach on how to prevent API drift between a test mock and an actual implementation.

One of the risks of writing your own test doubles is that the API of the double can fall out of sync with the API of the real implementation.

In this screencast I walk through an example that explains:

  • How interfaces can provide a false sense of security
  • Why tests make better contracts than interfaces
  • How to run multiple implementations against a shared set of contract tests

If you’ve ever had issues with API drift, try this approach and let me know how it works for you.

https://adamwathan.me/2016/02/01/preventing-api-drift-with-contract-tests/

Read more

Testing your composer dependencies with prefer-lowest

An older but still relevant post by Evert Pot on why and how you should also test your packages with the lowest versions of it's dependencies.

In some projects, there may be packages lying around that are not the latest version. This could be because it introduced some BC break, or introduced a bug.

If other packages also use the package that’s being held back, they may get an older version as a dependency.

So for package maintainers, they will want to find out if their package correctly works with the oldest package they claim to support.

https://evertpot.com/testing-composer-prefer-lowest/

EDIT: Here's another old, but also still relevant, blogpost on the subject by Cees-Jan Kiewiet:

https://blog.wyrihaximus.net/2015/06/test-lowest-current-and-highest-possible-on-travis/

Read more

Understanding dependency injection containers

At the heart of many modern PHP application there is an IoC Container, short for inversion of control container. When people talk about a "dependency injection container" or a "service container" they mean the same thing. It's purpose is to manage class dependencies. Though the concept is relatively simple, it can come across very confusing if you've never worked with one.

In a new post on his blog Matt Allan builds a simple one from scratch. Check it out if you're struggling with understanding how the IoC container works.

If you are writing modern PHP, you will run across dependency injection a lot. Basically all dependency injection means is that if an object needs something, you pass it in. ... Dependency injection makes your code more flexible and easier to test.

http://mattallan.org/2016/dependency-injection-containers/

EDIT: mattalan.org seems to be down, but you can still view the post in Google's cache.

Read more

Facebook's mobile device lab

As a user I've pretty much turned my back to Facebook, but boy must it be interesting to work at that scale. Here's how Facebook built their mobile device lab.

... We needed to be able to run tests on more than 2,000 mobile devices to account for all the combinations of device hardware, operating systems, and network connections that people use to connect on Facebook. Today, in our Prineville data center, we have a mobile device lab — outfitted with a custom-built rack — that allows us to run tests on thousands of phones. The process of building a lab in our data center wasn't a direct path, and we learned a lot along the way...

https://code.facebook.com/posts/300815046928882/the-mobile-device-lab-at-the-prineville-data-center/

Screen Shot 2016-07-15 at 21.23.13

I stumbled on this story via Bram.us. Subscribe to the RSS feed of that site if you haven't done so already.

Read more

Acceptance Testing a Laravel and Vue.js Application

Mohammed Said did some research on how run acceptance test for a javascript driven interface.

If you’re testing non-javascript driven interfaces then you may use Laravel’s built-in PHP Browser based testing library, it’s very powerful and the API is very readable as well. However if you need to test javascript driven interfaces then selenium is what you should be using.
https://dotdev.co/acceptance-testing-a-laravel-and-vue-js-application-4160b8e96156#.j1ltb34zv

Read more

Type Wars

The venerable Uncle Bob makes the case for dynamic typing and TDD. Be sure to read the entire article to get a quick history lesson in computer languages.

The pendulum is quickly swinging towards dynamic typing. Programmers are leaving the statically typed languages like C++, Java, and C# in favor of the dynamically typed languages like Ruby and Python. And yet, the new languages that are appearing, languages like go and swift appear to be reasserting static typing? So is the stage for the next battle being set?

How will this all end?

My own prediction is that TDD is the deciding factor. You don't need static type checking if you have 100% unit test coverage. And, as we have repeatedly seen, unit test coverage close to 100% can, and is, being achieved. What's more, the benefits of that achievement are enormous.

http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html

Read more

Approaches to Testing: A Survey

The last few months have been my first opportunity to do automated testing at my full-time job. As I’ve been trying to get the hang of it, my biggest question has been how many of each type to test to write: how many unit, integration, and acceptance tests. Turns out Folks Got Opinions™ on this! As I researched, I found at least four different approaches to testing, and they each provide different answers to a number of questions I had.
http://codingitwrong.com/2016/02/08/approaches-to-testing-a-survey.html

Read more