views:

61

answers:

2

This may be a dumb question, but do you make unit tests for the HTML output of your PHP functions/scripts?

I try to keep my HTML and my PHP separate - i.e. HTML includes with placeholders, and functions for certain recurring elements (tabular data / any sort of looped output) - but I'm not sure how to go about verifying this.

Is there a standard way to go about such things, or is it mainly a matter of using regular unit tests on functions which create the inserted content, and then making sure it looks correct in the browser/W3C Validator?

Thanks.

Edit: I guess a corollary to this would be: are these sorts of unit tests even worth having? If you're keeping your content and structure properly separated, then you would really only be testing a handful of includes in very limited scenarios (presumably, anyway). Is it really worth it to semi-hand-craft full pages just to have a file to compare to?

+2  A: 

You can use PHPUnit. It has Output testing.

http://www.phpunit.de/manual/3.0/en/testcase-extensions.html

NullUserException
This raises a similar question: Is it really worth it to semi-hand-craft full pages like this just to have a file to compare to for a few unit tests? Wouldn't it be visible when it breaks?
Kristina
@Kristina If you are testing huge, monolithic parts of your program you are missing the point of [unit testing](http://bit.ly/dezkGz)
NullUserException
@NullUserException: The individual functions and methods making up the page can be checked, but you're saying I shouldn't unit test the method that calls them/renders the page?
Kristina
+1  A: 

Testing for HTML output would be considered a coverage test. Initially, when I started using PHP I was creating these tests, but over time I found that these tests weren't really all that helpful.

If there is one thing that I know, it is that the presentation is going to change a lot from initial development to deployment.

If you think about it, a for loop really is not logic but is a isometric transformation function, and if you follow Separation of Concerns, Then you are passing the data into the for loop via a method of some sort. I would recommend testing that the for loop gets the correct data, but not the output of the for loop.

If you find yourself repeating yourself in generating tables then by all means start unit testing those table templates. But once again, you'll find that those templates will be seeing a lot of change.

At this point you should be looking at separating the iteration from the HTML output to help isolate yourself from these concerns in your tests.

One way to do this is to use a mapping function, it will take a list and transformation function and perform the function on each item in the list, then return the transformed list.

Usually, when creating tables, I end up with two for loops in creating a row.

  1. Iterate over all rows.
  2. While in (1) iterate over items in row.

Pretty ugly to unit test that, but with closures you can create function generators that would really be easy [this is said with a grain of salt] to implement.

Gutzofter