perl-qa,
I forward this here to pose a few questions;
is there a right way to set up a 3 process test within the Test::*
Framework ?
I borrowed the approach used in LWP t/robot/ua.t, but added a 2nd fork/spawn
to give the 3 layers.
Is there a good way to borrow tests from another distribution ?
Im using several pieces of W3-Mech tests.
tia,
jimc
Original Message
Subject:a 3 process test for HTTP::Recorder
Date: Sat, 13 Dec 2003 22:43:10 -0700
From: Jim Cromie <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Hi Linda, HT-Proxy folks.
Ive built a test-setup for HTTP::Recorder, a young module with
a high potential usefulness. For easy experimentation, Ive supplied it
as a patch against HTTP-Recorder-0.01. I send here cuz its
mentioned on htproxy's home page.
The test -setup is still quite rough, but Ive tweaked it for while now,
and would appreciate a fresh set of eyes. Please send any suggestions
for improvements, or actual fixes here; I trust BooK wont mind,
and I imagine that Linda will watch this for progress.
More detail is in the t/README, but here are the highlights.
3 process layers:
client layer: uses WWW::Mechanize to conduct tests.
htrec layer: runs an HTTP::Recorder/Proxy in separate process
htdaemon layer: serves up content to support tests.
Tests are basically in mech layer, but must be written to test the
HTREC/HTPROXY layer; probably by testing that the expected HTML
transforms are done in the htrec layer. Further complicating things,
daemon must supply the expected pages, etc.. a tedious coordinating
job unless good decisions are made.
htdaemon slings pages foreach t/htdocs/*.html
htrec/htproxy env-proxys to daemon.
mech-layer talks to localhost:1025 (not 'proxied')
mech-layer scripts can retest thru htrec-layer.
!instant tests!
The setup borrows from W3Mech and LWP; I copied W3Mech /t/*.html to
t/htdocs/, and t/find_link.t will attempt to repeat w3mech tests here,
thru the htrec layer, and will eventually be followed by other t/*.t
pilferings ;-). The daemon layer is borrowed and adapted (with added
cruft!) from LWP t/robot/ua.t
diff -Nru HTTP-Recorder-0.01/MANIFEST HTTP-Recorder-0.01-test/MANIFEST
--- HTTP-Recorder-0.01/MANIFEST Sun Jul 27 21:33:31 2003
+++ HTTP-Recorder-0.01-test/MANIFESTSat Dec 13 16:34:14 2003
@@ -4,5 +4,19 @@
Makefile.PL
t/load.t
t/pod.t
+t/README explains new stuff
+t/all3.pl 3 process test, to be renamed to all3.t
+t/find_link.pl 1. w3mech driver
+t/htrec.pl 2. htproxy/htrec layer UNDER TEST
+t/htdaemon.pl 3a. daemon test support services
+t/daemon-loop.pl 3b. daemon boilerplate
+t/mechtest.t borrowed, will delete
+#
+t/htdocs/area_link.htmlborrowed, served by daemon-layer
+t/htdocs/field.html
+t/htdocs/find_link.html
+t/htdocs/frames.html
+t/htdocs/google.html
+t/htdocs/tick.html
MANIFEST
README
diff -Nru HTTP-Recorder-0.01/recording HTTP-Recorder-0.01-test/recording
--- HTTP-Recorder-0.01/recordingWed Dec 31 17:00:00 1969
+++ HTTP-Recorder-0.01-test/recording Sat Dec 13 15:32:30 2003
@@ -0,0 +1 @@
+$agent->get("http:/find_link");
diff -Nru HTTP-Recorder-0.01/t/README HTTP-Recorder-0.01-test/t/README
--- HTTP-Recorder-0.01/t/README Wed Dec 31 17:00:00 1969
+++ HTTP-Recorder-0.01-test/t/READMESat Dec 13 17:50:07 2003
@@ -0,0 +1,136 @@
+
+=head1 new test strategy: 3 layer harness, 3 process stack. (A Dagwood)
+
+ client layer: uses WWW::Mechanize to conduct tests.
+ htrec layer: runs an HTTP::Recorder/Proxy in separate process
+ daemon layer: serves up content to support tests.
+
+Tests are basically in mech layer, but must be written to test the
+HTREC/HTPROXY layer; probably by testing that the expected HTML
+transforms are done in the htrec layer. Further complicating things;
+daemon must supply the expected pages, etc.. a tedious coordinating
+job unless good decisions are made.
+
+ Daemon slings pages foreach t/htdocs/*.html
+ htrec/htproxy env-proxys to daemon.
+ mech-layer talks to localhost:1025 (not 'proxied')
+ mech-layer scripts can retest thru htrec-layer.
+ !instant tests!
+
+The setup borrows from W3Mech and LWP; I copied W3Mech /t/*.html to
+t/htdocs/, and t/find_link.t will attempt to repeat w3mech tests here,
+thru the htrec layer, and will eventually be followed by other t/*.t
+pilferings ;-). The daemon layer is borrowed and adapted (with added
+cruft!) from LWP t/robot/ua.t
+
+=head1 client layer
+
+t/all3.t attempts to integrate all 3 processes in 1 file, and
+successfully spawns the daemon-layer, but has some probs spawning the
+htrec layer. Could also be called master layer, esp wrt spawning.
+
+t/find_link.pl actually runs the 1st tests, and is invoked by all3.t
+via do "file".
+
+On its 1st get(), the script fails, as browser shows.
+
+ Scheme is not
