1. Site based foxy fixtures

    beforeFoxy

    We used to fill the fixtures (test data) files with ids and obscure numbers. That was long and difficult to understand (plus it was error prone).

    foxy

    With the new fixtures format, we write much fewer lines and there is no risk of error in the inherited attributes as they are automatically calculated.

    Yes, these 3 lines is all there is for this node.

    site based fixtures

    But that’s not the best part. The real joy is that you can just create a folder in test/sites and fill it with fixtures files and these are scoped for the given site. You can then write specific tests that use these fixtures either by adding site: a_name to a yaml test (zena_parser, node_query, etc) or by setting the global variable $_test_site:

    class NodeTest < ZenaTestUnit
      def setup
        $_test_site = 'foobar'
      end
    
      def test_names
        login(:admin) # if 'joe' is only participating in 'foobar', the $_test_site setting is not needed
        node = secure!(Node) { nodes(:foo) }
        assert_equal groups_id(:public), nodes.rgroup_id
      end
    end
    

    In the example above, node :foo and group :public exist only in ‘foobar’ site.

    This should make it easy to adapt zena without touching the fixtures to test root functionalities. I hope you enjoy, it was really painfull to go through all tests removing the ids left and rewriting the 60 node fixtures (with versions and content…) as you can see in the huge changset.

    Gaspard Bucher