PHPUnit getMock takes a possible seven params.

They are, in order:

1. String – Required – the class name to mock
2. Array – Optional – the methods to mock
3. Array – Optional – arguments to pass to the mock’s constructor
4. String – Optional – a class name for the mock
5. Boolean – Optional – disable the call to the original class’ constructor
6. Boolean – Optional – disable the call to the original object’s clone method
7. Boolean – Optional – disable autoload during the mock object creation

The getMock implementation can be found on github, in the phpunit-mock-objects repo, in Generator.php.

Documentation on what I just explained can be found in the PHP 3.4 docs with arduous searching (see Table 22.6 TestCase), but I’ve not found the same page in the 3.5 docs.

I’ve never used beyond the third argument to getMock, so I have no idea how useful the rest are.

PHPUnit getMock Method Signature

The order of the arrays clearly mattered in our tests, so what was causing them to change that we didn’t expect?

Short version:

In the tests we were using PHPUnit’s assert functionality to test that two arrays were equal. If the ordering between the two arrays is off, even if they contain the same key value pairs, PHPUnit will fail the test. Comparing arrays in this way normally works, because PHP usually guarantees array order; however, under some circumstances order is not guaranteed. This was the cause of the random failures. To fix this, we just need to be smarter about how we compare arrays.

Long version:

In investigating one of the tests that was failing randomly, I saw that it was performing an assertEquals on two arrays. Sometimes this assert would fail because the ordering in one of the arrays had changed for that test run.

The question that is relevant here is this: does PHP guarantee the order of arrays?

The answer: it depends.

PHP arrays are implemented under the hood as an ordered map – what is essentially a Linked Hash Map in Java. Insertion order is guaranteed. However, PHP breaks this contract for some array functions, such as array_slice, which does not guarantee order unless a flag is set.

In the case of the test I investigated, the final array was being generated by an array_slice that was buried in the code. One potential fix is to change the code under test so it does not use array_slice or so the flag to maintain order is set. The other fix is to make the tests smarter.

I opted to go with option two, making the tests smarter. This can be done by using compare functions such as array_diff or array_diff_assoc and then asserting on the output of the compare function instead of asserting for equality between two arrays. Another option is to sort the output array, so it always has the same order. Your creativity is the limit on how you solve this.

What does this episode indicate? That it is worth understanding how the language you’re using operates. While PHP has more warts than most, all languages have idiosyncratic behavior that it is worth being aware of. The next time you see perplexing behavior, ask yourself why it’s happening and investigate. The reasoning why the language is behaving as it is might surprise you.

Randomly Failing PHP Tests

Find the Erlang version you’re running:

erlang:system_info(otp_release).

To clear a variable/binding, so it can be used again:

f(variable_to_clear).

Show all the running erlang processes:

erlang:processes().

Find more useful tips from Joe (such as how to ping a node with a dash in the name).

Helpful Erlang Tidbits

Poaching isn’t difficult.  You bring water to a boil, drop in chicken, add spices, ignore. After the chicken is cooked, pull it out, continue with dish. I was disappointed in that the spices didn’t add much, if any, flavor to the chicken; however, they smelled spectacular while the chicken cooked. The chicken was amazingly tender. It almost shredded itself for the enchiladas.  It is difficult to get chicken this tender using other cooking techniques; it would takes a watchful eye and careful hand.

From this experience I added a new skill to my cooking repertoire. I now know poaching’s strengths and weaknesses.  Had I not been venturous, I wouldn’t have grown as a cook. In coding, it’s the same.  If I never leave my comfort zone, I never learn new techniques. I can keep writing code using the same methods and same tools, but it’s akin to frying chicken every night. It’s good at first, but eventually you get tired of it and it might kill you.

Spice is the variety of life. Try a new technique and see what it teaches you. By knowing how to use an array of tools you have the skills to program in any situation. It’s the same as knowing multiple ways to cook chicken:  you can always prepare the chicken, no matter what kitchen you find yourself in, so you never go hungry and never tire of practicing your trade.

Poaching Chicken and Code

So asks Neil Gaiman on NPR in a story on audiobooks.  It makes for riveting listening, thanks to Gaiman’s ability to make the mundane fantastic and because he has a mesmerizing British accent that holds me rapt.

Gaiman makes the point that audiobooks continue on, strong as ever.  The rise of the iPod has only made them more popular.  Given our information starved yet saturated world it seems the ceiling for audiobooks is limitless – until the day we can download information directly. Even then, there’s always a market for a good story.

So what is an audiobook? Gaiman wonders.

According to audio producer Rick Harris: “Well, my feeling is that it is not a book.”

“An audiobook is a separate entity that is absolutely true.  And a novel can be seen as many things, and one of the things it can be seen as is a script for an audio performance.”

Gaiman sums up: “An audiobook is its own thing, a unique medium that goes in through the ear, sometimes leaving you sitting in the driveway to find out how the story is going to end.”

As an audiobook is its own thing – separate from, but attached to, a book.

So to a program is its own thing – separate from, but attached to, code.

For what is code, except a script that is read by the compiler/interpreter?  We developers just happen to count on the compiler/interpreter reading the script we give it the same way every time, even though there is nothing that dictates this must happen.

It would be an interesting world to have a compiler/interpreter that put its own spin on the code given it.  To an extent, this does happen now, except in reverse.  You and I can write dialects of the same code and the compiler/interpreter will read it and spit back the same performance, even though it was based on two different scripts.

Code as performance.

I grew up in a world where stories were read aloud
- Neil Gaiman

What would the world be like if code was read aloud?

http://www.flickr.com/photos/playfullibrarian/3315024196 / CC 2.0

Book as Script, Code as Script