Unit testing in PHP? [duplicate]

Question

I've been thinking about writing unit tests for my PHP/MySQL projects.

The thing that bugs me is how i can test things like form validation, ajax features, and UI features (such as clicking links). Also, I don't want the tests to be dependent on one aspect of the UI, so if I moved one link then all tests would break.

Does anyone have any ideas/suggestions on what parts of the code I should unit test, approximately how much time should be spent on unit testing, and any other suggestions/tips?

Answer 1

You should thumb through this part of the documentation of SimpleTest and look at the methods they have for testing

• page content
• navigation
• cookies
• images
• frames
• form submission
• redirects
• proxies

Even if you don't end up using SimpleTest, it may be worth a look.

To me, the most useful thing is testing form submissions, including each parameter in a GET or POST request for each form that is necessary for the operation of your site.

Whether you want to test a lot of your UI or just small key areas is up to you.

Answer 2

Unit tests, at least from a web application development standpoint, can't really cover UI design. What unit tests can help you with is to test the input/output of all your controller methods and/or any singleton/global functions you have hanging around. So, if you want to get unit test coverage on your form validation, make sure your application is structured in such a way that you can test your validation function independent of the UI.

class SomeController extends ... {
    ... function isAPhoneNumber($string){
        if(...) {
            return true;
        }
        else (...) {
            return false;
        }
    }
}

This does leave all the code that gets your value TO this method untested. The only effective way I've seen of testing this is to test the UI directly with browser remote controls like Selenium. The PHPUnit testing framework has hooks for using Selenium's PHP driver, which means you can use the same test runner as your other unit tests.

You're never going to be 100% assured that an innocent change won't hork your Selenium tests, but there are steps you can take during development to minimize this. Selenium has various different ways to "target" an element it will click on or type in. You want to use targeting that is as specific as possible, so try to give all your (X)HTML nodes a unique ID element. This ensures that selenium will click a link no matter where it ends up on a page.

When a unique id is not possible, try to wrap common elements with some HTML element that has a unique identifier, and then use selenium's xpath tareting abilities to say "click the link that contains the text "signup" that's in the div with the id of "foo", or click the third link in the div with the id of "foo".

If it's not obvious from the items above, do not rely on the targeting choices that Selenium IDE (or other recorders) will pick. Their goal is to ensure that running the test on that exact page will give you the same results, which can give you very fragile xpath. Always review the tests you record, and fix-up shoddy targeting.

There are no easy answers here. If there were, web applications would be a lot less buggy.