![]() |
![]() |
![]() |
Expectations | Simple Test PHP Unit Test Framework | Testing forms |
Testing classes is all very well, but PHP is predominately a language for creating functionality within web pages. How do we test the front end presentation role of our PHP applications? Well the web pages are just text, so we should be able to examine them just like any other test data.
This leads to a tricky issue. If we test at too low a level, testing for matching tags in the page with pattern matching for example, our tests will be brittle. The slightest change in layout could break a large number of tests. If we test at too high a level, say using mock versions of a template engine, then we lose the ability to automate some classes of test. For example, the interaction of forms and navigation will have to be tested manually. These types of test are extremely repetitive and error prone.
SimpleTest includes a special form of test case for the testing of web page actions. The WebTestCase includes facilities for navigation, content and cookie checks and form handling. Usage of these test cases is similar to the UnitTestCase.html...
Nothing is being tested yet. We can fetch the home page by using the get() method...
Assuming that the web server for the Last Craft site is up (sadly not always the case), we should see... Web site tests OK Test cases run: 1/1, Failures: 0, Exceptions: 0 All we have really checked is that any kind of page was returned. We don't yet know if it was the right one.
To confirm that the page we think we are on is actually the page we are on, we need to verify the page content.
Here is the list of possible content assertions...
assertTitle($title) | Pass if title is an exact match |
assertText($text) | Pass if matches visible and "alt" text |
assertNoText($text) | Pass if doesn't match visible and "alt" text |
assertPattern($pattern) | A Perl pattern match against the page content |
assertNoPattern($pattern) | A Perl pattern match to not find content |
assertLink($label) | Pass if a link with this text is present |
assertNoLink($label) | Pass if no link with this text is present |
assertLinkById($id) | Pass if a link with this id attribute is present |
assertNoLinkById($id) | Pass if no link with this id attribute is present |
assertField($name, $value) | Pass if an input tag with this name has this value |
assertFieldById($id, $value) | Pass if an input tag with this id has this value |
assertResponse($codes) | Pass if HTTP response matches this list |
assertMime($types) | Pass if MIME type is in this list |
assertAuthentication($protocol) | Pass if the current challenge is this protocol |
assertNoAuthentication() | Pass if there is no current challenge |
assertRealm($name) | Pass if the current challenge realm matches |
assertHeader($header, $content) | Pass if a header was fetched matching this value |
assertNoHeader($header) | Pass if a header was not fetched |
assertCookie($name, $value) | Pass if there is currently a matching cookie |
assertNoCookie($name) | Pass if there is currently no cookie of this name |
So now we could instead test against the title tag with...
Users don't often navigate sites by typing in URLs, but by clicking links and buttons. Here we confirm that the contact details can be reached from the home page...
If the target is a button rather than an anchor tag, then clickSubmit() can be used with the button title...
The list of navigation methods is...
getUrl() | The current location |
get($url, $parameters) | Send a GET request with these parameters |
post($url, $parameters) | Send a POST request with these parameters |
head($url, $parameters) | Send a HEAD request without replacing the page content |
retry() | Reload the last request |
back() | Like the browser back button |
forward() | Like the browser forward button |
authenticate($name, $password) | Retry after a challenge |
restart() | Restarts the browser as if a new session |
getCookie($name) | Gets the cookie value for the current context |
ageCookies($interval) | Ages current cookies prior to a restart |
clearFrameFocus() | Go back to treating all frames as one page |
clickSubmit($label) | Click the first button with this label |
clickSubmitByName($name) | Click the button with this name attribute |
clickSubmitById($id) | Click the button with this ID attribute |
clickImage($label, $x, $y) | Click an input tag of type image by title or alt text |
clickImageByName($name, $x, $y) | Click an input tag of type image by name |
clickImageById($id, $x, $y) | Click an input tag of type image by ID attribute |
submitFormById($id) | Submit a form without the submit value |
clickLink($label, $index) | Click an anchor by the visible label text |
clickLinkById($id) | Click an anchor by the ID attribute |
getFrameFocus() | The name of the currently selected frame |
setFrameFocusByIndex($choice) | Focus on a frame counting from 1 |
setFrameFocus($name) | Focus on a frame by name |
The parameters in the get(), post() or head() methods are optional. The HTTP HEAD fetch does not change the browser context, only loads cookies. This can be useful for when an image or stylesheet sets a cookie for crafty robot blocking.
The retry(), back() and forward() commands work as they would on your web browser. They use the history to retry pages. This can be handy for checking the effect of hitting the back button on your forms.
The frame methods need a little explanation. By default a framed page is treated just like any other. Content will be searced for throughout the entire frameset, so clicking a link will work no matter which frame the anchor tag is in. You can override this behaviour by focusing on a single frame. If you do that, all searches and actions will apply to that frame alone, such as authentication and retries. If a link or button is not in a focused frame then it cannot be clicked.
Testing navigation on fixed pages only tells you when you have broken an entire script. For highly dynamic pages, such as for bulletin boards, this can be crucial for verifying the correctness of the application. For most applications though, the really tricky logic is usually in the handling of forms and sessions. Fortunately SimpleTest includes tools as well.
Although SimpleTest does not have the goal of testing networking problems, it does include some methods to modify and debug the requests it makes. Here is another method list...
getTransportError() | The last socket error |
showRequest() | Dump the outgoing request |
showHeaders() | Dump the incoming headers |
showSource() | Dump the raw HTML page content |
ignoreFrames() | Do not load framesets |
setCookie($name, $value) | Set a cookie from now on |
addHeader($header) | Always add this header to the request |
setMaximumRedirects($max) | Stop after this many redirects |
setConnectionTimeout($timeout) | Kill the connection after this time between bytes |
useProxy($proxy, $name, $password) | Make requests via this proxy URL |
![]() |
![]() |
![]() |
Expectations | Simple Test PHP Unit Test Framework | Testing forms |
Documentation generated on Sun, 04 May 2008 09:21:12 -0500 by phpDocumentor 1.3.0