Hi Marc,
I think I misunderstood your intentions with verifyContent
vs compareToExpected. While compareToExpected had some
issues which needed fixing, it did perform some functionality
which seems to have now gone with verifyContent.
In particular, the ability to create the reference file
the first time you ran the test seems to have gone.
This is pretty key because in general it is very hard to
potentially create the reference file except by applying
the same filters later used when verifyingContent.
Two uses cases we have:
(1) A PDF file is generated from a third-party templating
system. The customer address, barcode etc are removed from
the PDF using a custom filter. This becomes the reference
file the first time the test is run. If the template is
changed, we simply delete the reference file and it is
recreated.
(2) A web service returns a zipped file as an attachment.
Using a custom filter, the attachment is extracted from
the web service response, unzipped and some of the
information contained within an XML file within the zip
becomes the reference file.
Is there a plan that would allow verifyContent to handle
these scenarios? I think we should not deprecate
compareToExpected until we have such functionality in place.
Paul.
Marc Guillemot wrote:
Hi,
I've several problems with current compareToExpected step:
- name doesn't fit with all our verifyXXX steps
- if reference file doesn't exist, it looks silently for it in a
subfolder named "expected"
- it doesn't fail if reference file doesn't exist at all but just
creates it
- it doesn't fail if an IO error occurs
Therefore I propose to deprecate compareToExpected and to introduce a
verifyContent which would offer the same functionalities as
compareToExpected but in a more deterministic way. This would look like:
<verifyContent referenceFile="someFile.xxx".../>
Any thoughts?
Marc.
_______________________________________________
WebTest mailing list
[email protected]
http://lists.canoo.com/mailman/listinfo/webtest
