I just realized that I have started doing a form of testing which is not quite
unit tests but has similar features. Basically, I write XQuery's that analyze
the output result and report on things in a way that makes it easy to see if
the result is as expected.
For example, I'm currently implementing code that recognizes various forms of
citation and adds markup for them in existing XML. To test my result I use this
XQuery (I'm using it from Oxygen against a single result but could of course be
used in a more automated way or across a corpus using an XQuery database):
(: Report the citations by total count, unique value, and count per value :)
declare namespace map = "http://www.w3.org/2005/xpath-functions/map";;
let $fedcites := //*:span[@class = 'cite-federal-reg']
let $statecites := //*:span[@class = 'cite-state-statute']
let $fedmap as map(*) := map:merge(
(
for $cite in $fedcites
return
map{
string($cite) : $cite}
),
map{ 'duplicates' : 'combine'}
)
let $statemap as map(*) := map:merge(
(
for $cite in $statecites
return
map{string($cite) : $cite}
),
map{ 'duplicates' : 'combine'}
)
return
<cite-analysis>
<fed-cites total="{count($fedcites)}">{
for $key in (map:keys($fedmap) => sort())
let $instances := map:get($fedmap, $key)
return <citation count="{count($instances)}">{$key}</citation>
}</fed-cites>
<state-cites total="{count($statecites)}">{
for $key in (map:keys($statemap) => sort())
let $instances := map:get($statemap, $key)
return <citation count="{count($instances)}">{$key}</citation>
}</state-cites>
</cite-analysis>
This produces a result like:
<cite-analysis>
<fed-cites total="32">
<citation count="2">15 USC 78</citation>
<citation count="2">33 USC 1251</citation>
<citation count="1">33 USC 1292</citation>
<citation count="1">33 USC 1317</citation>
<citation count="2">40 CFR 136</citation>
<citation count="2">40 CFR 136.3</citation>
<citation count="1">40 CFR 2.302</citation>
<citation count="1">40 CFR 261</citation>
<citation count="1">40 CFR 261.21</citation>
<citation count="1">40 CFR 403</citation>
<citation count="2">40 CFR 403.13</citation>
<citation count="1">40 CFR 403.15</citation>
<citation count="1">40 CFR 403.5(a)(2)</citation>
<citation count="1">40 CFR 403.6(a)(4)</citation>
<citation count="2">40 CFR 403.6(c)</citation>
<citation count="2">40 CFR 403.6(e)</citation>
<citation count="1">40 CFR 403.8(f)(6)</citation>
<citation count="2">40 CFR 405—471</citation>
<citation count="1">44 CFR 59.22</citation>
<citation count="1">44 CFR 59.22(a)(9)(v)</citation>
<citation count="1">44 CFR 60.3</citation>
<citation count="1">44 CFR 60.3(c)</citation>
<citation count="1">44 CFR 60.3(d)</citation>
<citation count="1">7 USC 2012</citation>
</fed-cites>
<state-cites total="137">
<citation count="1">Code of Virginia, § 1-200</citation>
<citation count="1">Code of Virginia, § 10.1-100</citation>
<citation count="1">Code of Virginia, § 10.1-1127.1</citation>
<citation count="2">Code of Virginia, § 10.1-1414</citation>
<citation count="1">Code of Virginia, § 15.2-107</citation>
<citation count="1">Code of Virginia, § 15.2-1100</citation>
<citation count="1">Code of Virginia, § 15.2-1400</citation>
<citation count="1">Code of Virginia, § 15.2-1425</citation>
<citation count="1">Code of Virginia, § 15.2-1429</citation>
<citation count="1">Code of Virginia, § 15.2-1430</citation>
<citation count="2">Code of Virginia, § 15.2-1432</citation>
<citation count="1">Code of Virginia, § 15.2-1433</citation>
<citation count="1">Code of Virginia, § 15.2-200</citation>
<citation count="2">Code of Virginia, § 15.2-2200</citation>
<citation count="9">Code of Virginia, § 15.2-2204</citation>
...
<citation count="1">Code of Virginia, § 62.1-255</citation>
</state-cites>
</cite-analysis>
That makes it easy to see what's being added to the source and whether or not
the result is consistent with expectations. I could refine this, for example,
to report things that should have matched but didn’t (for example, look for
"Code of Virginia" that *isn't* within the wrapping <span> elements my code is
adding).
This kind of analysis produces a much more controlled result that would be
amenable to putting into a repeatable unit test.
--
Eliot Kimber
http://contrext.com
On 10/16/18, 4:00 AM, "Tom Cleghorn tom(_dot_)cleghorn(_at_)arm(_dot_)com"
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
On 15/10/18 20:41, Pieter Masereeuw pieter(_at_)masereeuw(_dot_)nl wrote:
> It would be interesting to know if there are readers on this list who
> actually make use of units test during XSLT development and what their
> experiences are.
I've also always found unit testing XSLT a little too painful to
actually get on with and *do* - especially when working on pre-existing
code.
However, I've recently been getting promising results by generating
XSpec tests from a set of requirement docs filled in by stakeholders -
these still need some dev massage before they're ready to produce
working scenarios, but in the context of this particular project, it's
proving a good way to both discipline the code (not to mention the
coder...) and prevent regressions, and provide a window on to the things
stakeholders care about - i.e. what goes in and what comes out, rather
than what happens on the inside.
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--