Entries with the tag “phpunit”

I’m not a huge fan of todo comments in code because I think they’re mainly forgotten. However, I don’t have the same opinion for PHPUnit tests. Let’s talk about why - and how to easily add them in your code.

Since you’re a programmer, you’re always looking for ways to be a bit more efficient. Because of this, it can be easy to fall into the trap of being too programatic, too calculation-heavy in your unit tests. But, this isn’t a test then - its just another block of quite fallible code. Let’s talk about why and show what to do instead.

When your unit test suite gets larger, it can take quite a long time. One of the many ways to speed this up is to hunt down and fix slow tests. Let’s use PHPUnit’s test listeners to do just that.

It’s great to run code coverage at the very end before you push your changes. This gives you some idea what’s tested and what’s not. But you don’t have to wait till the end; code coverage can help you all throughout writing your test suite, too.

Please stop using assertDatabaseHas in Laravel. There are many reasons why this is bad, and there are better options available. Let’s find out why.

There are a lot of debates about trying to achieve test coverage of 100%. Some people swear you need to do this. Others say, get 80% or more… the rest doesn’t matter. Each side has strong arguments.

There’s a struggle to balance the easy-to-use Laravel helpers and functions with very verbose, complicated methods in unit tests. As I’ve been relying on Laravel’s way of doing testing more, I’ve ran into a couple of gotchas that I should share.

I started noticing a disturbing trend on one of my projects: developers were doing too much logic in the setup and data provider methods of their PHPUnit tests. However, before we could address this, a “limitation” popped up which helped them kick this habit.

I wrote instructions in 2011 to add a PHPUnit Listener to Watch for Long Running Tests which seem to be a bit out of date now. But, here’s a quick refresher:

Often times, I find myself targeting a single file with PHPUnit by specifying the file after the binary in the command line:

From time to time, I get thrown onto a project that has many, many errors in the unit tests. It can be hard to try to figure out what to fix first with so many errors on the screen. Sadly, I’ve had my scroll-back buffer filled many times.

When you’re testing inside of your PHPUnit test methods, you will use many assert-based methods. Two that are seemingly very similar are assertSame() and assertEqual()

I’ve written a few helpful methods and systems that help out my unit testing. There are many arguments for and against these tools (don’t test protected methods, don’t introduce global namespace methods, etc) - and those are discussions for another day - but perhaps these might help you out in the mean time.

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.

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.

Normally, when I write unit tests, I don’t use Laravel’s facade and fakery methods. I do a lot of injection of services, but in one particular case, when working with the Queue system, I had to use the facade for faking the queue and asserting some jobs were pushed.

I’m a huge fan of tools like PHPUnit. Or any other tool that will help my project carry on.

I’ve been working with Pimple Dependency Injector lately, and I’ve come up with an interesting question.

If you’re not familiar with having PHP QA Tools, go there right now! And then come back and read this.

For the most part, ZF can capture any of your hard errors. It will generate an error 500. You’ve seen them, don’t lie… I’ve seen them way too many times. However, in my production application, I capture these with a specific controller. And because I love Unit Testing, I want to make sure that I test my implementation of my omg-this-is-broken setup.

I was looking at mock objects in PHPUnit the other day and started to get confused. When I asked for a Mock object, the entire object was a mock. In all actuality, it wasn’t so much a Mock of the object but a complete shell of it.

By default, PHPUnit is not part of the default installation of Eclipse PDT. (Zend Studio is another beast, however…)

If I need to run PHPUnit on a remote system against a code suite, I will write a simple shell script like the following to do it for me. (Bonus points, you can even include this as an External Tool in eclipse to do it right from your project).

One of the under-utilized features of PHPUnit probably is the listeners interface.

First, I just want to say up front that this is not a discussion of “is 100% test coverage necessary” or a discussion about testing private methods. This is simply how you may do it if you wanted to.

One of the steps to install PHPUnit is to execute the following pear commands:

Running a test, I ran into this error: