Ant Support
CI tools like Jenkins are able to call any script, but my first idea for build automation is always Ant. I have some history with Ant but most likely I use it because I am an old school Java developer ;-). Fortunately Ant has build-in XSLT support which I can use to apply the XSLTunit template.
<property name="test_prefix" value="tst_" /> <property name="test_result_suffix" value=".test_result.xml" /> <!-- apply style to XMLs in suite --> <xslt basedir="${suite}" destdir="${suite}" style="${suite}/${style}"> <include name="*.xml" /> <exclude name="*${test_result_suffix}" /> </xslt> <!-- apply test --> <xslt basedir="${suite}" destdir="${suite}" style="${suite}/${test_prefix}${style}" extension="${test_result_suffix}"> <include name="*.xsl" /> <exclude name="${test_prefix}*.xsl" /> </xslt> <!-- create readable HTML test report --> <xslt basedir="${suite}" destdir="${suite}" style="${basedir}/lib/xsltunit_report.xsl"> <include name="*${test_result_suffix}" /> <param name="testname" expression="${style}" /> </xslt>My approach contains a lot of "convention over configuration". For example I assume that each template
${style}
is located inside its own folder ${suite}
. The given Ant target first transforms sample data with the template under test for manual review, then applies the test case to the template and finally generates a readable report out of the test result. The first and last step is optional but useful during development. In the end the test result is checked for the text "failed"
which shows a failed assertion.<dirname property="suite" file="${testResult}" /> <loadfile property="test_failed" srcFile="${testResult}" /> <fail message="Test ${suite} failed!"> <condition> <contains string="${test_failed}" substring="outcome="failed"" /> </condition> </fail>Testing and checking the result is done for all templates in the source folder
${src}
by using <foreach>
from Ant-Contrib.<foreach target="-testFolder" param="foreach"> <path> <fileset dir="${src}"> <include name="**/*.xsl" /> <exclude name="**/${test_prefix}*.xsl" /> </fileset> </path> </foreach> <foreach target="-verifyResult" param="foreach"> <path> <fileset dir="${src}"> <include name="**/*${test_result_suffix}" /> </fileset> </path> </foreach>
FizzBuzz Kata
After the unit tests were executed by Continuous Integration for each commit, I went for some XSLT exercise. Unfortunately adding the Ant support had taken too much of my scheduled learning time and I had to work with the smallest kata available, the FizzBuzz question: Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz". I wrote the following template by following a few XSLTunit tests.
<xsl:template match="value" mode="fizzbuzz"> <xsl:choose> <xsl:when test="number(current()) mod 15 = 0">FizzBuzz</xsl:when> <xsl:when test="number(current()) mod 3 = 0">Fizz</xsl:when> <xsl:when test="number(current()) mod 5 = 0">Buzz</xsl:when> <xsl:otherwise><xsl:value-of select="." /></xsl:otherwise> </xsl:choose> </xsl:template>To solve the complete question I applied the template to the values of 1 till 100,
<numbers> <number><value>1</value></number> <number><value>2</value></number> <number><value>3</value></number> <number><value>4</value></number> ... <number><value>100</value></number> </numbers>which generated a HTML file with the answer of the FizzBuzz question.
- for 1 say 1
- for 2 say 2
- for 3 say Fizz
- for 4 say 4
- ...
- for 100 say Buzz
2 comments:
Speaking of FizzBuzz, you might be interested to read this
Dimitre, thank you for pointing that out to me. I did not know there was so much interest in FizzBuzz using XSLT. I had googled for XSLT and FindBuzz but as kata variant which includes the unit tests in some way.
Where I was just dabbling with XSLT 1.0 I see that these XSLT 2/3 solutions are amazing. Well done!
Post a Comment