Structuring tests in php-amqplib, the most used PHP library for RabbitMQ

Repository

https://github.com/php-amqplib/php-amqplib

Introduction

RabbitMQ is a popular message broker which enables to defer time-consuming tasks like file conversions, sending emails, or report generation, just to name a few, in order to provide a good user experience to your web visitors.

A message broker is great for web applications to run tasks on the background due to the nature of the HTTP protocol, which is stateless. In other words, requests must be performed quickly because you don’t want users to wait time until a resource-intensive task is completed.

Learning to scale apps with RabbitMQ is out of the scope of this post – please read the tutorials to get familiar with work queues as well as to learn more about the publish-subscribe pattern.

There are practical examples in Python, Java, Ruby, PHP and many other programming languages; so chances are that you can use a RabbitMQ library in your app right now.

Technology Stack

• RabbitMQ 2
• PHP
• PHPUnit
• The php-amqplib library

Bug Fixes

Using RabbitMQ in PHP apps is a snap with php-amqplib, the most widely used PHP client for RabbitMQ.

However, in my opinion adding new features is not a great experience from a developer perspective since the library's current testing scaffold, which is written in PHPUnit, still needs some tweaking.

More specifically, what brought me to start structuring the tests was the fact that I wanted to remove the BC Match extension -- if that makes any sense -- as it is suggested at bcadd and bcmul are replaced by built-in operators #573, but found that couldn’t do it very easily.

So, the PR Structuring tests #574 cleans up a little bit the previous testing structure. It also introduces a few conventions when it comes to writing the tests as described in the following boilerplate PHPUnit code.

class FooTest extends TestCase
{
    public function setUp()
    {
        // ...
    }

    public function tearDown()
    {
        // ...
    }

    /**
     * @test
     */
    public function the_name_of_this_test_has_underscores_to_be_readable()
    {
        // ...
    }

    /**
     * @test
     */
    public function another_test()
    {
        // ...
    }

    /**
     * @test
     * @expectedException \PhpAmqpLib\Exception\AMQPInvalidArgumentException
     */
    public function this_one_throws_an_exception()
    {
        // ...
    }

    /**
     * @dataProvider fooData
     * @test
     */
    public function this_test_uses_a_data_provider($value, $expected)
    {
        // ...
    }

    // public methods here (camelCased) 

    // private and protected methods here (camelCased)
}

The name of the methods are written in snake case in order to be a bit more readable. On the other hand, it is recommended to write PHPUnit's setUp() and tearDown() methods at the beginning of the class. Data providers are written below the testing methods as a rule of thumb, and exceptions are tested through annotations.

IMHO, a boilerplate is always a good starting point that will help to build a nice testing scaffold for any app. The important thing actually is to stick with a convention for the sake of consistency.

Finally, let me remind how to run the tests just in case you’d want to contribute now as well:

git clone [email protected]:php-amqplib/php-amqplib.git
cd php-amqplib
composer install
vendor/bin/phpunit 

Thanks so very much for reading.

GitHub Account

https://github.com/programarivm