Entries with the tag “testing”

I love the Spatie Laravel Permissions package. I use it in almost all of my Laravel projects.

When testing, I’ll need to set up users with various different roles and permissions. Usually, I’m using an Eloquent Factory in order to accomplish this.

But it’s a little different when you’re dealing with relationships. Let’s find out how.

What’s the difference between unit test, integration test, and a feature test? Which should you use for what type of test? Is it just preference or does performance factor in when using Laravel? Let me give you my take from over a decade of unit testing experience.

Should I be writing more unit tests? Integration Tests? End to End tests? I can’t answer this completely, but I can give you one tip to help you decide 80% of the time.

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.

I’m a sucker for those little badges at the top of the README files in Github repos. I know you can get them from external services, but could I host my own? Let’s find out.

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.

tldr; Using Sqlite in Laravel (or most PHP apps) for unit testing causes false positives in unit tests. Things that work will not work when you move to production and use a different db like MySQL. Instead, spin up a test database that is the same tech and engine as your application will be.

When you’re trying to demo your work in progress to a client, it can be difficult to know where to draw the line between working and non-working features. On one hand, you want to show them some context so they can understand the current feature. But, then what happens when they invariably try to explore the context (which may not be done)? Let me put that in a more concrete example.

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.

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.

In an earlier post titled Use $this->fail() with Mockery::on(), I explained the challenges of debugging a failing test with the closure passed to Mockery::on(). Instead of returning false, I opted to use $this->fail() - which seemed like a good idea at the time. After all, I was doing my test, then failing with a useful bit of information. (Previous to this, it would just say that you don’t have a matching handler for this assertion, which was really confusing).

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

It’s important to unit test your application code - even your console commands. So many times, I’ve seen people using the Artisan facade inside of console commands to either queue up new commands or call a different command. This makes it more difficult to unit test the application - you have to rely more on fakery (requiring you to reset your application each time then) and/or integration tests.

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()

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.

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.

In a perfect world, when testing your website you’d have a giant device library, a number of different internet connection speeds, and a bunch of users using the system simultaneously. A perfect world? Pfffft. But, I can help you at least get close to this set of requirements for your test. Let’s see how we can use Google Chrome to simulate different devices and change our internet connection speeds.

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

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.

I love working in the Zend Framework view system. One thing that bothers me, however, is that I must create a complex set of models when trying to send email. I decided that I’d like to move all of this output for the mail class into my own view system as well.

So, while chatting with one of the developers on my team, we started talking about testing an XML document creation process he had been working on. He wrote a unit test and said “see, here is my class which generates the XML, and then here I use DomDocument to add the nodes I know it will have and test against that.”

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.

I was creating a new application with Zend Framework at work the other day and I started using my technique that I described here by adding the original email in my email address using the + sign. However, the current organization I’m at has a mailserver (Exchange?) that is either configured not to allow this or just doesn’t have this functionality built in. So, this won’t work. I solved this with a new implementation of the mail class.

I recently came across this tutorial here about Testing with TPTP - and I’m confused. What’s the benefit of this type of testing (um… creating JAVA code for a JUnit test… right?) compared to running some PHPUnit, Selenium and AB (from apache, or something…)? What am I missing - does anyone have any other good hands-on tutorials?

A while ago, I discovered the ‘joys’ of APD… and then more so, the ‘joys’ of not being able to make heads or tails out of the output script. After digging deeper, I saw that the original directory already had some PHP scripts to parse the output. I ran those and wasn’t very impressed. Even more important, my boss wouldn’t be impressed. I needed to be able to make something that could be useful to integrate into a table (I finally used dojo to create a table…)

I was reading on a forum the other day about some benchmarks for PHP. The guy had posted some results in ms measurements, and was getting upset about his erratic results. There were some things that he was forgetting, however.

(“the triangle”) just recently purchased a book for the library at my request, Test-Driven Development by example by Kent Beck. The current Amazon price for this book is $35. The book took me about 2 weeks of sporadic reading to finish. The first section took the first week, the remaining 2 sections and appendix flew by.