Tels ha scritto:
-----BEGIN PGP SIGNED MESSAGE-----
Moin,
On Wednesday 02 November 2005 16:45, Marcello wrote:
Tels ha scritto:
-----BEGIN PGP SIGNED MESSAGE-----
[snip]
I'm considering just using Test::WWW::Mechanize to do integration
testing through a Web server I run in the tests. This will be much
faster and allow me to get my development speed back up. However,
I'd be skipping the unit testing of the output. I'll catch the bugs
but it will likely take me longer to track them down.
I feel your pain. The test suite for Handel has xml/tt output tests
for its AxKit and Template Toolkit plugins. I've got oodles of
template pages using the components whos output I compare to static
.out files that contain the expected output.
Everytime I write a new plugin, or a new tag in the plugin, I waste
tons of time just writing the tests for them. So far, I've been good
about writing the tests before I write the code, but it takes forever
and I rarely get the tests right the first time.
I'm curious to see what comes out of your question. I'm in the same
boat.
I am somewhat in the same boat with Graph::Easy - the t/ascii.t
script tests rendering of graphs in ASCII, ala:
[ A ] -> [ B ]
is transformed into:
# echo "[Test] -> [This] ..> [ Now ]" | perl examples/as_ascii
+------+ +------+ +-----+
| Test | --> | This | ..> | Now |
+------+ +------+ +-----+
While this works mostly fine for ASCII, the HTML/SVG is undertested
because the text/code output can change quite radically, while still
rendering/representing the same graph. And of course I do want to
test that the end result is the right one, not that the generated
SVG/HTML code is a specific example.
If the output is valid xml, couldn't one "semantically" compare the
expected output and the actual output with something like
XML::SemanticDiff ?
Might be, but I am not generting XML, but HTML...
Valid XHTML is also valid XML.
And there are many ways to write code that looks visually the same, and
yet is wildly different. More so for, lets say SVG.
My point was that 'semantically' comparing XML data structures instead
of their ascii representations is an improvement.
Of course this doesn't take into account specific cases like SVG, where
you have 'semantically' different xml documents producing the same
(visual) output.
To address this specific case one would need a way to test the 'visual'
equivalence of two svg documents.
Sometimes I resort to "soft" tests, like looking if I find certain strings
in the output, like for "[ Bonn ] -> [ Berlin ]", you expect "Bonn" and
"Berlin" in there somewhere...
Best wishes,
Tels
- --
Signed on Wed Nov 2 17:17:05 2005 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
"Build a man a fire, and he'll be warm for a day. Set a man on fire, and
he'll be warm for the rest of his life." -- Terry Pratchett
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iQEVAwUBQ2jm5HcLPEOTuEwVAQFI1Af+J5xwJopUDR/eLJ/AtyeVPrAxiwcF5Mt+
ikOj8jmLI0uwQ5bqrj74Ad+XNQxTOIoiu7ItecF0aAjQRMBWBm4wp+/bsSIgFdBr
6substw3TSNYaCeQTU95IVXQV1CNcerpnuC5SVdmIE9l+PJOUAZHWSa3QJLcLD7e
bFg9Fj4WlJsdc1FY9+l+qzXnfFwTSpZoF9ExvVQlBsilEJNOfcUgbHzXnqE/Kt0i
GTuNHrxPse+Lt+j25Kv2vBygQ94opiH/MEVM2jIED68nUESYhGJGNPZm23gvXRy7
CQw2qdmB6mHfXw3fEYB5E99nQn0rLP45KCcdm4AkEjBuSNNkBnuzpw==
=5jrY
-----END PGP SIGNATURE-----
--
Marcello Romani
Developer
Spin s.r.l.
Reggio Emilia
http://www.spinsoft.it
