[drupal-devel] Unit tests in Drupal.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I know there has been some discussion regarding this in the past, but I was wondering what it would actually take to get Drupal into a state where we take advantage of unit testing. As I have stated before, the most of my time spent maintaining the postgres port is spent testing every little thing in the system, and anything to automate that would help me, and by extension Drupal, immensely. Any thoughts ? - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCjxYCgegMqdGlkasRAtLLAJ4wy1XmaTGSLIx/82a7A5yB1s77gACfWGn/ WnsHfDt10emthkkRviRcy/o= =BwUV -----END PGP SIGNATURE-----
On Sat, 21 May 2005, Adrian Rossouw wrote:
I know there has been some discussion regarding this in the past, but I was wondering what it would actually take to get Drupal into a state where we take advantage of unit testing.
Moshe made some initial commit somewherein cvs...
As I have stated before, the most of my time spent maintaining the postgres port is spent testing every little thing in the system, and anything to automate that would help me, and by extension Drupal, immensely.
Any thoughts ?
What I'd look for is some way to actually testdrive Drupal without any human interaction. I am not sure this is the same as unit tests. On Drupal.org there is a small hint about using wget for this. Bèr has made some improvements recently. This way you can actually go to every link in Drupal and try it without spending much time yourself. You can look at the error logs afterwards. Problem: You can't post stuff. We'd need to have a script that puts stuff into fields and actually posts them. curl is able to do this and I bet there are scripts around that use it for finding exploits or whatever. Cheers, Gerhard
Problem: You can't post stuff.
Why? http://www.gnu.org/software/wget/manual/html_node/HTTP-Options.html --post-data=string --post-file=file NK
On May 21, 2005, at 6:45 AM, Gerhard Killesreiter wrote:
On Drupal.org there is a small hint about using wget for this.
This is from my upgrade tutorial. http://dev.bryght.com/t/wiki/ CivicSpaceUpgrade I added info about crawling with three types of account, setting images if that module is enabled. I also advised to check web server logs not only watchdog logs. Cheers, Kieran 2.5 Run a link check on the site. We now want to crawl your site, to get a list of dead links. This is a simple command that will help you identify broken parts of your site. You will see errors in you Administrator logs as well as your web server error logs. Perform these next commands through the administrator menu on your site. Enable image admin module Set permissions so images can be written for userid running link check. Enable the menu module, and then disable the logout menu. Run wget with the following options. The cookie this command is referring to is the cookie downloaded from your browser when you last logged into your CivicSpace site as an admin. NOTE: You can see the full and original wget instructions here: http://drupal.org/node/11521 wget -r --delete-after --cookies=off --header='Cookie: PHPSESSID=xxx' http://yoursite.com -r to recursively crawl the site. --delete-after, --cookies=off tells the crawler not to use a cookie. --header=’Cookie: PHPSESSID=XXXX’ tells the site that session information will be passed in the http header. This should be repeated 2 more times; once for a regular userid, and once for an anonymous userid. After the link check is done check your admin logs and your webserver error logs.
Hey: Chris Shiflet and Geoff Young gave a good presentation about testing PHP applications using Apache-Test: "Testing PHP with Perl: Two Great Tastes that Taste Great Together" on October 26, 2004 at NYPHP. http://www.nyphp.org/content/presentations/index.php Chris has spoken about this elsewhere and continues to do do more talks and refinements on it. Here's a blog post from him in March: http://shiflett.org/archive/106 --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
On May 21, 2005, at 4:05 AM, Adrian Rossouw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I know there has been some discussion regarding this in the past, but I was wondering what it would actually take to get Drupal into a state where we take advantage of unit testing.
As I have stated before, the most of my time spent maintaining the postgres port is spent testing every little thing in the system, and anything to automate that would help me, and by extension Drupal, immensely.
Any thoughts ?
The main resource for finding OSS testing tools is: http:// opensourcetesting.com Here are link checkers: http://www.opensourcetesting.org/ link_checkers.php http://linkchecker.sourceforge.net/ http://j-spider.sourceforge.net/ http://htcheck.sourceforge.net/ Functional testing: jWebUnit http://jwebunit.sourceforge.net/ WebInject http://www.webinject.org/ You should know I am currently running a testing program for the contribution modules we add to CivicSpace. My testing plan is here: http://civicspacelabs.org/home/node/12441. I'd be happy to extend this testing phase to Drupal core if I could get some help managing it. Cheers, Kieran
- -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin)
iD8DBQFCjxYCgegMqdGlkasRAtLLAJ4wy1XmaTGSLIx/82a7A5yB1s77gACfWGn/ WnsHfDt10emthkkRviRcy/o= =BwUV -----END PGP SIGNATURE-----
On Sat, 21 May 2005, Kieran Lal wrote:
On May 21, 2005, at 4:05 AM, Adrian Rossouw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I know there has been some discussion regarding this in the past, but I was wondering what it would actually take to get Drupal into a state where we take advantage of unit testing.
I thing we need to distinguish between unit testing (as proposed by Moshe) and checking the generated html as proposed by me using wget (or similar tools). Moshe's simpletest module will actually call our PHP functions and execute them, checking the results. The other method will test the whole site and provided functionality from the outside. It is obvious that Drupal can benefit from both methods.
The main resource for finding OSS testing tools is: http:// opensourcetesting.com
Here are link checkers: http://www.opensourcetesting.org/ link_checkers.php http://linkchecker.sourceforge.net/ http://j-spider.sourceforge.net/ http://htcheck.sourceforge.net/
Those probably implement the sort of crawler that I made from wget.
Functional testing: jWebUnit http://jwebunit.sourceforge.net/ WebInject http://www.webinject.org/
Those are more interesting. I've had a look at their manual and despite the fact that I don't like XML I think we could for example created the following test: 1) user logs in 2) user goes to node/add/foo 3) user posts new node. We could create typical user paths by looking at the data that drupal.org collects and create test cases for them.
You should know I am currently running a testing program for the contribution modules we add to CivicSpace. My testing plan is here: http://civicspacelabs.org/home/node/12441.
Will look at it later. Cheers, Gerhard
Testing is good. 1) Unit tests for module developers is a good idea. I looked at phpunit but development has stopped and it's not easy to configure. 2) Crawlers to check sites after an upgrade is also a good test, and I think we should leave wget in the manual but start looking at recommending other crawlers with examples. There are specific regular expressions that would be useful when crawling a site and wget can not handle them. For instance, not crawling admin is a good idea. 3) Functional testing is valuable. If we can have non-programmers create scripted tests with xml this is another thing that non- programmers can contribute to the community. Webinject seems to be a good OSS solution for this. Cheers, Kieran
I have built a decent framework for running unit tests in drupal. all thats needed is for modules and core to develop 'tests'. Tests are small php files which will likely ship with your module. i have already written tests for the validation functions in user.module. I hope developers will take an interest in this effort. See http:// cvs.drupal.org/viewcvs/drupal/contributions/modules/simpletest/ -moshe On May 21, 2005, at 7:05 AM, Adrian Rossouw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I know there has been some discussion regarding this in the past, but I was wondering what it would actually take to get Drupal into a state where we take advantage of unit testing.
As I have stated before, the most of my time spent maintaining the postgres port is spent testing every little thing in the system, and anything to automate that would help me, and by extension Drupal, immensely.
Any thoughts ? - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin)
iD8DBQFCjxYCgegMqdGlkasRAtLLAJ4wy1XmaTGSLIx/82a7A5yB1s77gACfWGn/ WnsHfDt10emthkkRviRcy/o= =BwUV -----END PGP SIGNATURE-----
participants (6)
-
Adrian Rossouw -
Daniel Convissor -
Gerhard Killesreiter -
Karoly Negyesi -
Kieran Lal -
Moshe Weitzman