Mabel Needs Unit Tests

A while back, I wrote a post about updating a big chunk of existing unit tests in the php-common library so that they worked with php 7.4 and phpunit 7. I knew that there was a much more recent version of phpunit, but I didn't want to tackle familiarizing myself with the up-to-date version by converting an existing set of unit tests.

So, given that I needed to write unit tests for the code I'd added to Mabel I figured it was the perfect time to dive into PHPUnit 9.

I have to say that I was pleasantly surprised. The api for PHPUnit is a lot cleaner now. It's not significantly different but it's more streamlined. The organizational structure is more obvious with a clear hierarchy that helps you to select the right methods for the case you're dealing with. The documentation is less complicated and more straightforward as a result and I found that to be a great help.

Case in point, I was writing a test that required me to mock an object representing an instantiation of the Predis/Client class. That particular class uses a lot of "PHP magic" that allows php code to interact with the a live instance of redis. Unfortunately, because of that magic, the class didn't actually contain the methods I needed to mock so that they would return the correct values for my tests.

As it turns out, the old-school way of handling this (use the setMethods method of the mock builder) was deprecated, and while my unit tests all passed the results were besmirched with deprecation warnings. Digging into the code I figured out that, by design, there's no way to suppress deprecation warnings in PHPUnit. Basically, the editorialization here is that you should upgrade your code to the current api rather than figure out how force your tests into a passing state.

Looking at the specific method that had been deprecated I saw that it had a link to a pull request in the github for phpunit. Amazingly, this pull request had an entire comment thread associated with it that:

1. Explained a corner case that a user was concerned about (which happened to be similar to my situation)
2. A suggestion of methods to add to the api to address the users concern.
3. A discussion of the suggestion that resulted in the decision to implement largely what the user suggested.
4. A description of the schedule by which these changes would be made to the api.

Honestly, the whole thing just made me feel very confident about phpunit as a piece of software and php as a whole. It obviously not a dying language and both the language and the community around it are obviously improving and evolving in a direction of more simplicity, clarity, logic and performance.

Anyhow, the unit tests for the current revision of Mabel are done.