1. just for fun

    zafu implementation

    Implementing unknown link :

    Parser tests:


    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

    Finished in 0.516126 seconds.
    60 tests, 60 assertions, 0 failures, 0 errors

    Zena tags tests:


    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
    Finished in 7.408223 seconds.
    103 tests, 130 assertions, 0 failures, 0 errors

    Yes, tests for zena tags are slower because each test does two calls to the TestController, one for compilation in the controller’s context and the second to render with the test data. For example, this is a test for traductions:

    each_traductions:
      src: "<z:traductions><ul><li do='each'><z:show attr='title'/></li></ul>\
    </z:traductions>"
      tem: "<% if list1 = @node.traductions -%><ul><% list1.each do |var1| -%>\
    <li><%= var1[:title] %></li><% end -%></ul><% end -%>"
      res: "<ul><li>Etat des travaux</li></ul>"
    

    But in most complex tests, we only check for the final result:

    children_else_block:
      src: "<z:children>I am tired !<z:else>I am not a parent.</z:else>\
    </z:children>"
      res: "I am tired !"
    

    Creating a parser without tests like these would be impossible for me. I love test driven development ! Now the hardest part in writing software is not debugging anymore, it’s writing the test infrastructure…

    We are not doing pure ‘test driven’ development, because we usually start by writing some user’s manual with examples to clearly focus on the user’s needs and not on our views, this is more like a mixture of extreme programming, literate programming, test driven development and nerd...

    Gaspard Bucher