Tels ha scritto:
-----BEGIN PGP SIGNED MESSAGE-----

Moin,

On Friday 28 October 2005 22:34, Christopher H. Laco wrote:

Ovid wrote:

The code is designed well enough that adding new features is quick
and easy. Unfortunately, whenever I need to change my code I fire up
a Web server and view the results in the browser and then write the
tests after I've written the code (this is closely related to When
test-driven development just won't do). This is because XML and XHTML
are just text. I need to see the output. I've been finding more and
more that small changes in my code are making huge changes in the
output and trying to continuously update the tests to exactly match
the XML, XSLT and XHTML using Test::XML and XML::XPath has led to a
serious productivity drop.

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 ?

Just my 0.2 eurocents...


So everytime I change the HTML template/output, I need to fiddle back a host of tests...

Best wishes,

Tels

- -- Signed on Fri Oct 28 23:33:31 2005 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Ok, a shiny copper piece to the first person who can tell me why Elan
 is running around naked." - "Giant moth attack?" - "Maybe a bad guy
 casted 'Dispel clothes'?" - The Order of the Stick issue #26

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQ2KZ9ncLPEOTuEwVAQEZxAf/Rz/gxvA3w2bbD7D1CfT2HaFe+glj37kT
WkJUQ7pj9bEZA/o74WJwpdZyL7MfTe3K6MhqohstrNDL9XxvN0C0ScSQiHlagHny
zVl6gdZ9DDhxWBOzHZc5oEdrsV6qhkHkdvusADC3mTb0UZEqgE50RbgERw1Wlu1v
08O5NWmqJTI+KDujqdY5FZ6pBSGUR72eiaWw8UxN7HkSi42DP8/dmnw+23FsVTmc
z3sJhNuhaNsVorMHdPHxUs9n5WuXRP/h1cemrrzpx2o3SfP4DBiDoxt0GKMdeRiB
s29F8bWWQ4CLUsQqAgk9L4P7fOp00+tqDBLr/9t/ECLiVxWDFTxcWg==
=b8rX
-----END PGP SIGNATURE-----



--
Marcello Romani
Developer
Spin s.r.l.
Reggio Emilia
http://www.spinsoft.it

Reply via email to