iPath's unittest

Before re-factoring and introducing new functionality, you must secure your accomplishments. A well known way of securing code is the use of unit tests: isolating code (functions or methods) and check the result of your programming logic against verified output obtained earlier. The greater part of your code is covered by unit-testing, the more you're guarded against breaking logic when re-factoring or extending your existing code base.

The logical input for SVG (hence the output of iScriptDesign's functionality) is simple text, easy enough to do comparisons against and define unit-tests on them.

A few test frameworks for javascript are available. IScriptDesign is using Jasmine, at the moment of selection the most vivid project. A typical Jasmin unit-test looks like:

  it ("should form a symmetrical line", function() {
       expect(symmetry([[{x:30,y:20},{x:20,y:30},{x:40,y:30}]],0)) 
          .toEqual("c 30 20 20 30 40 30 c 20 0 10 -10 40 -30 "); 
  }); 
--{ listing 4a, A unit test }

Although seasoned programmers may find the omission of the well known "assert statements" confusing, I think that the "expect(..).toEqual(..)" terminology contributes to readability for the less seasoned programmers. When the function "symmetry" is modified and it does not produce the outcome we specified in the toEqual() part, this particular unit test fails. You'll be able to identify and locate the problem faster. Once the problem is found you should reconsider your code modifications (or the reference outcome for your unit test). We can of course also use a unit test for double checking idempotent logic:

  it ("should check idem-potency", function() { 
             expect(myPath.rotate(myPath, Math.PI/4).reverse(myPath).dPath(1))
           .toEqual(myPath.reverse(myPath).rotate(myPath, Math.PI/4).dPath(1)); }); 
--{ listing 4b Check idem-potency in code. (code will be explained in detail below). }

A unit test may of course also be used to guarantee behaviour of new functionality (introduced below).