Simplifying Unit Testing (and asking for help when needed)

**Do you test your application in the right way? Or do you attempt to do it all at once, in many locations? When you’re stuck, do you ask for help?

**Do you test your application in the right way? Or do you attempt to do it all at once, in many locations? When you’re stuck, do you ask for help?


Recently I was a bit stuck, trying to figure out how to test a section of an application I’ve been developing. Specifically, I was trying to mock a HydratingResultSet in a controller test, so it could be the return value of a method call on a datasource, my controller needed.

I was sure it was the right approach to help ensure the functionality in question was working properly. But no matter what I tried, my tests didn’t work, because I wasn’t mocking it correctly. So, after some time experimentation, I did what I do increasingly often, jumped in to #zftalk on IRC.

I asked for help, laying out the problem as I saw it. The first response which came back, from Ocramius, stopped me dead in my tracks:

Why are you trying to do that?

Honestly, I’d not stopped to think if it was the right thing to do. I’d simply assumed it was. The moment he gave the response, I took another look at my code and began seeing the error of my ways. _Why was I trying to mock up a HydratingResult in the first place? _

As a bit of background, my controller action iterates over a ResultSet, using \Zend\Paginator\Paginator. This class is either constructed using an Iterator or an ArrayAdapter; essentially it uses a traversable object.

Said another way, I’m always working with an array of model objects, no more no less and, the way I construct the Paginator object, it wouldn’t matter if that was all I passed to it, even empty array.

I heard Ocramius’ reply again:

Why are you trying to do that?

Good question, why was I? Honestly, I still had no answer.

Based on that, I revisited the code in question and simply created an array of model classes, calling exchangeArray to initialize them. Then I set the generated array of model objects as the return value, from my mock object. Result? The tests ran perfectly.

Nb: for mocking, I’m a big fan of Padraic Brady’s Mockery library. Works a treat, and easily interchangeable with PHPUnit’s mock objects.

Why This Long Story?

I’ll answer that with some questions. When you’re testing your classes are you:

  • Attempting to do too much?
  • Attempting to mock code not required in the current context?
  • Attempting to test code either multiple times or not in the correct place?

When you’re testing a controller, you’re not testing your model classes, right? The two are distinctly separate. Take for example, a simple case of iterating over a list of results in a controller action.

When testing the action, you assume that the classes which provide the data to your are fine, or at the very least, outside the domain of responsibility of the action’s test; as they’re covered by their own tests.

All you’re concerned about here, is what happens with the information provided by them. For example, say you had logic in your view template, which would exclude certain records from being displayed, based on something in the user’s profile.

Say you were listing departmental users, but the user could only view records for their department, specifically. However, if they were a manager, they could see records for all departments, not just their own.

You would then write, at least, two tests; one for a manager, and one for a standard user, likely using an XPath assertion, to check the response body.

If there’s an error in the generation of the information however, you’d add more test in the model classes, not in the action tests. Right?

Can you see the separation of concerns? Can you also see how taking this approach makes life a lot easier?

When you’re stuck - do you ask for help?

When you’re stuck, what do you do? More than likely, go directly to either Google or StackOverflow. I’m not going to criticise, I do this too, quite often. I know countless people who do, as well. And there’s nothing wrong with it.

But here’s a further admission; I’ve been for many years, what Troy Hunt calls, the ghost who codes.

It’s rather a catch-22. Whether you feel you’ve made a newbie mistake, a silly mistake, or feel you’ll get flamed for even asking, you make up any number of excuses (_which you tell yourself are valid reasons_) for not asking someone for help.

If you do ask someone for help, invariably the next thing you do is start making qualifying excuses, such as “please don’t judge me too harshly, but…”

I wrote it in a hurry / The budget was really tight / The manager was yelling at me to finish it

For these and many other reasons, we don’t ask. But we should. After all, a cliché as it, how are we ever going to learn otherwise?

I’ve done and still do make excuses not to ask. But when I just asked people, the responses have been great and the rate at which I’ve improved has been staggering.

For that reason, today I’m encouraging you to set your pride, ego and excuses aside and when you’re stuck: ask for help.

Not everyone is so helpful as the one’s I’ve encountered, but most people are. Just remember to ask a question directly and be a bit patient.

If you have a Gist link handy too, that will go a long way, as it’s much easier to write one up, with a good description and then share a link to it, than to try and verbally describe it in the channel.

Winding Up

I appreciate today’s post has involved no specific code samples, but they’re important topics which need to be covered. What’s your experience with testing and asking for help? Share your thoughts in the comments.

Creative Commons Attribution-Noncommercial 2.0 Generic License  by  fore 

You might also be interested in these tutorials too...

Wed, Nov 6, 2013

Basic Zend Framework Testing With Mockery

Do you need to mock objects in your Zend Framework 2 applications and find PHPUnit unintuitive, even difficult? If so, come and learn Mockery instead.

Mon, Oct 19, 2015

How to Test Zend Framework Applications with Codeception

Testing is essential for creating reliable software. Whether you’re writing a small application for your local club or an application to back your startup, it needs test coverage to ensure it works properly. In this series, I show you how to test Zend Framework 2 applications using the comprehensive testing framework - Codeception.

Want more tutorials like this?

If so, enter your email address in the field below and click subscribe.

You can unsubscribe at any time by clicking the link in the footer of the emails you'll receive. Here's my privacy policy, if you'd like to know more. I use Mailchimp to send emails. You can learn more about their privacy practices here.

Join the discussion

comments powered by Disqus