I haven't looked at the code yet but I read the docs and I really like the idea. I think it would be better to use a name under the Test::* namespace, though. Perhaps something like Test::CheckWeb. | [reply] |
It seems to me that you are going about it all wrong. If you want to check the web server configuration, why not just check the web server configuration? Modules already exist to parse the Apache configuration format, etc. Instead of testing the indirect result (which may be influenced by other things), go to the source. You already need access to the web server to put your HTML files there. See if you can find the configuration files too.
If you want to check HTML that comes back from the webserver, there are already plenty of HTML testing modules out there. You don't need to come up with your own module because you have a particular use for these things. Test::Harness, Test::WWW::Mechanize, etc. can already do the sorts of things you need and already provide a widely-used, widely-tested, and generally accepted way of doing things. Modules such as HTML::Tidy, Test::HTML::Tidy, and the like will help you do more while writing less of your own code.
It seems to me that a better name would be something such as Test::WWW::Server::VerifyFeature. In any case, you need to find a top level namespace for this.
Good luck :)
| [reply] |
I think the main thing I need to do is improve my documentation. I don't think I made myself clear.
This thing doesn't check configuration at all, it checks if features are working properly by getting web pages that use those features.
The thing that's different about my approach is I can write a single perl script and point it at any compliant test web page.
With Test::WWW::Mechanize, you have to write a web page that uses a feature and a specific script that looks at that web page. With my system, you write the web page and all you have to do with the script is point it at the web page.
Here's a scenario example:
I have 3 web servers, they each do SSI and PHP, but only one has a mysql server. I write a web page that uses some SSI features, another web page that uses some PHP features and another web page that connects to the mysql server and does a few things. I copy the 1st two pages to all 3 servers and the mysql test page only to the server with mysql. Now, I can either use Test::WWW::Mechanize and write
a script or scripts that know exactly what to expect from all of those web pages, or I can write my one script that will be able to understand them all.
And! If I decide that I want to test another aspect of, say my PHP interpreter, I only need to edit the test web page. I can leave my script alone. Much more scalable!
| [reply] |