In my Laravel application, I have an end point that will retrieve a collection of Client models. I have many other unit tests that validate that my repository returns the proper clients when requested, that my client model is sound. My last test is a feature test checks that if I retrieve a list of clients from the end point there is proper pagination and client models exist. I don’t really need to test the exact values because I know this will work - from all my other tests.
If you deal with integers, you validate them, right? You make sure they’re a valid integer? Well, what about the value 9223372036854775808? That’s right, that’s one more than the PHP_INT_MAX on a 64 bit system.
When you have a more complex assertion you need to make on the parameters of a mocked object, you might use the Mockery::on() method. It can be hard to tell how this fails, though, because if the assertion fails somewhere, the message is confusing - it basically says that there was no matching call to that method, which is technically correct.
A nice feature of Laravel is the ability to add a listener to the DB object’s events (or SQL queries). I’ve seen some people add this, then comment it out when it’s done, then un-comment it if they need it again. I don’t like that - I don’t want commented code in my files (also that’s why we have version control).
A pet-peeve of mine is pagination that doesn’t work properly. One that I ran into lately with Laravel is related to the pagination system it has built in. I was able to request pages that were larger than the last page with no discernible error. So, I decided to write a middleware to handle this issue for all of my content.
Sometimes it’s the little things that get you. This is more of just a reminder than anything else. One of the fun quirks (and I hesitate to call it a quirk because it’s technically working as defined) in PHP.
I’m very lucky to receive multiple LinkedIn requests to connect each week. I rarely accept them, unless I happen to recognize or know the person. Also, if they have a compelling message and I think they might follow up, then fine, too. But that’s where it usually ends…
I’m guilty of creating stub-like classes in my tests to unit test traits, sometimes. So, you end up with a special class inside your unit test file, perhaps at the bottom, that is empty but only extends the trait or something like that. This is not a good idea, but it was my only way that I could figure out how to unit-test traits separately - especially if they were made of protected methods.
Every PHP programmer knows you can’t extend multiple classes with PHP. You can only do one - which is fine. In fact, if you need more shared code, make sure to focus on using traits instead.
I hate to admit it, but I do like Laravel’s Tinker package. Sometimes, just testing out your relationships on the command line before you go further is super helpful.