How does JUnit (and the like) deal with web pages?

Post #101,103

5/9/03 2:45:32 PM

Most of what we write is web pages served up by PHP. Does JUnit allow you to define simulated HTTP POST/GET actions? Does it have a way of running PHP functions that are not called by the web server? (Later versions of PHP work from the command line so this will be less of an issue.)

I know these questions are fairly specific to PHP, which I know you don't do much (at all?). But I have zero experience with testing tools, so don't understand how they can be used to test individual functions within a PHP script.

===

Implicitly condoning stupidity since 2001.

Post #101,104

by admin

5/9/03 2:50:06 PM

Not really specific to PHP.

JUnit is a unit testing framework for Java code.

There is a Java framework called [link|http://httpunit.sourceforge.net/|HttpUnit], however, that can do GET, POST, manage cookies, parse HTML, etc. So HttpUnit in conjunction with JUnit is pretty good for testing web pages.

And in fact, looking at that page now for the first time in a few months I see that HttpUnit now [link|http://httpunit.sourceforge.net/doc/Javascript-support.html|supports some Javascript].

Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."

Post #101,107

by drewk

5/9/03 3:05:10 PM

Also from that page

Didn't see that link until after I posted, but there's [link|http://phpunit.sourceforge.net/|PHPUnit]. The docs are kind of sparse. It's hard to tell what are the example class names, and which are the actual PHPUnit classes, but I suppose that will make more sense once I have it installed.

===

Implicitly condoning stupidity since 2001.

Post #101,110

by admin

5/9/03 3:08:18 PM

HttpUnit is more useful for integration testing.

I've also used portions of it to simulate a web browser in 'screen-scraping' type applications.

Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."

Post #101,184

by static

5/10/03 12:17:17 AM

We use PHPUnit where I work.

If you do any kind of object programming in PHP, it will not be hard to figure out how to use it. We have one file per test class with multiple Test* methods that test things. Just be aware that you can't leave intermediate stuff hanging around between tests - it creates and destroys the test instance for each test.

Wade.

Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed

Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please

-- "Anything but Ordinary" by Avril Lavigne.

Post #101,146

by JimWeirich

5/9/03 5:30:28 PM

I'm experimenting with testing dynamic content ...

When you start using TDD seriously, your coding style changes to accomodate testing. Adding tests to an existing code base is hard. Writing tests as you go is easy.

So, the way you do dynamic content on a web page may change to facilitate the abiliity to test. I've not done any PHP work (so I'm not sure how applicable this is to your situation), but I began experimenting with some dynamic content test first approach. Here's what I'm trying out ...

First you separate your static page data from the dynamic part. We don't really care about testing the static part (why? ... ummm ... because it's static). We do care about making sure the dynamic content is correct however.

I choose to use a template system for the static content. The dynamic part choses the template and defines a set of name/value pairs used to populate the template based upon the input to that web page. Then my unit tests just exercise the dynamic portion and make sure that the proper name/value pairs are supplied with the desired template.

Example ...

\n   class LoginPage < Webpage\n     def update(cgi)\n       if valid_password(cgi['account'], cgi['password'])\n          next_page = select_template('start_screen')\n          next_page['account'] = cgi['account']\n       else\n          next_page = select_template('login_screen')\n         next_page['msg'] = 'invalid login, try again'\\\n       end\n       return next_page\n     end\n   end

And the unit test might look like ...

\n   class LoginPageTest\n     def test_good_login\n       page = LoginPage.new\n       cgi = {'account' => 'jim', 'password' => 'goodpassword'}\n       next_page = page.update(cgi)\n       assert_equal "start_screen", next_page.template_name\n       assert_equal "jim", next_page['account']\n     end\n\n     def test_bad_login\n       page = LoginPage.new\n       cgi = {'account' => 'jim', 'password' => 'boguspassword'}\n       next_page = page.update(cgi)\n       assert_equal "login_screen", next_page.template_name\n       assert_match /invalid login/, next_page['msg']\n     end\n   end

That's just a sketch of what I'm trying. I've glossed over some details. Any feedback is welcome.

--
-- Jim Weirich jweirich@one.net [link|http://w3.one.net/~jweirich|http://w3.one.net/~jweirich]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

Welcome to IWETHEY!