Friday, November 12, 2010

Automated Testing VS. Unit Testing

I often hear the terms Automated Testing and Unit Testing used in a context that implies that they are one in the same. Lumping these buzz words is misleading and can scare people away from implementing simple automated testing techniques.

Let me describe the two terms with out all the mumbo jumbo and TDD propaganda...

Unit Testing: Testing each part of your code at a granular level.

Automated Testing: Testing by using an automated process that can report success or failure.

Don't assume that to implement automated testing you need to start writing unit tests against all of your code. This is daunting and involves effort, planning, and a shift in paradigm. This is why most development teams shy away from automated tasting. In reality, there are much lower hanging fruit in the automated testing world than unit testing....



Suppose your application is supposed to output 10 folders into C:/web/, each with an html, javascript, and css file within them. So whenever you change your source code, you verify that everything still outputs. So your manually testing your code via something like this:
  1. Delete C:/web/
  2. Run your app with correct params
  3. Open C:/web/
  4. Verify folders and files exist
  5. Verify that there is data in the files
This is a fairly tedious test that could easily be automated. JUnit would be a great tool for this (Junit has an unfortunate name because it implies it is only for unit testing.) You could easily create a JUnit test that would do each step for you, and then display green for success or red for failure.

If your not yet doing automated testing, try to think of tasks that you do during development and testing that could be automated, forget about unit testing for now. Check out this article to learn how to create automated tests using JUnit. Like most it focuses on unit testing, but don't get hung up on that.

Monday, October 18, 2010

Removing line breaks in XSLT

I needed to remove the line breaks from my transform output because they were interfering with a 3rd party transform engine. (I could not use normalize-space(.) because I needed to preserve the spacing around mixed content.)

Instead of finding what the carriage return code is (I believe its #xD). I just created the variable $linebreak with the value of an actual linebreak.

The original code:
    <xsl:template match="para/text()">
<xsl:value-of select="."/>
</xsl:template>


Updated to remove line breaks:

<xsl:template match="para/text()">
<xsl:call-template name="selectWithoutBreaks"/>
</xsl:template>


Utilizes these templates:

<xsl:template name="selectWithoutBreaks" >

<!-- NOTE: The whitespace between the xsl:text elements is important because it represents the line break -->
<xsl:variable name="linebreak">
<xsl:text>
</xsl:text>
</xsl:variable>

<xsl:call-template name="replace-string">
<xsl:with-param name="text" select="."/>
<xsl:with-param name="replace" select="$linebreak" />
<xsl:with-param name="with" select="''"/>
</xsl:call-template>
</xsl:template>

<xsl:template name="replace-string">
<xsl:param name="text"/>
<xsl:param name="replace"/>
<xsl:param name="with"/>
<xsl:choose>
<xsl:when test="contains($text,$replace)">
<xsl:value-of select="substring-before($text,$replace)"/>
<xsl:value-of select="$with"/>
<xsl:call-template name="replace-string">
<xsl:with-param name="text" select="substring-after($text,$replace)"/>
<xsl:with-param name="replace" select="$replace"/>
<xsl:with-param name="with" select="$with"/>
</xsl:call-template>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="$text"/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>


This is all possible in XSLT 1.0. If you are using XSLT 2.0 you can use the replace function instead of creating the replace-string template above.