Refactor test interface

[patritzenfeld]

• Predicates/Queries are of type Reader (Picture,Components) a
• For animations, the type changes to Reader (Double -> (Picture,Components)) a
• Predicates can be given a label to promote them to a test (ReaderT env (Except String) ())
• An arbitrary amount of tests can be run yielding the label of the first failed test or the empty String if every test passed. (for direct use in the HUnit function assertString, which fails on any non-empty String)

Example use:

test :: [ Test ]
test =
  [ "scene =/= undefined?" ~: isDeeplyDefined Task02.scene
  , TestCase $ assertString $ testPicture Task02.scene $ do
      complain "Picture contains a trunk?" $ containsElem wood
      complain "Tree has at least a trunk and two branches?" $ wood `atLeast` 3
      complain "Tree has a green crown?" $ containsElem $ withColor green someSolidCircle
      complain "The trunk stands upright and there is a tree crown above it?" $
        hasRelation $ withColor green someSolidCircle `isNorthOf` uprightWood
      complain
        ( "Branches are roughly symmetrical? " ++
          "(if they already are, make sure your branches share code as much as possible)" 
        )
       $ containsElem (rotatedQuarter uprightWood) `ifThen` containsElem (rotatedUpToFull uprightWood) <&&>
         containsElem (rotatedUpToFull uprightWood) `ifThen` containsElem (rotatedQuarter uprightWood)
      complain
        ( "Branches are in the correct position? " ++
          "(They should neither cross, nor be detached from the trunk, nor be at level with the trunk)"
        )
        $ hasRelation (rotatedQuarter uprightWood `isAbove` uprightWood) <&&>
          hasRelation (rotatedUpToFull uprightWood `isAbove` uprightWood) <&&>
          hasRelation (rotatedQuarter uprightWood `isLeftOf` rotatedUpToFull uprightWood)
  ]
  where
    wood = withColor brown someSolidRectangle
    uprightWood = withColor brown someTallSolidRectangle

ToDo:

• adjust remaining tests

[patritzenfeld]

@jvoigtlaender can you take a quick look if there's anything you'd want to be different in the example config usage?

[jvoigtlaender]

That's the

test :: [ Test ]
...

listing above?

Looks good to me right now.

As an aside (apparently not relevant for the expressions in the tests, only their types and implementation): Maybe the pair in Reader (Picture,Components) should be replaced by something more abstract (later, as a refactoring)? I guess these will be accessed with fst/snd. Also, there is apparent redundancy, since presumably the components are derived from the picture. Maybe the environment should have a more abstract name/type, like Artefact or whatnot. Of course, it could internally still be a record with exactly the above two components, also retaining the fact that the components are explicitly stored in order to avoid their recomputation from the picture on each access; but instead of fst/snd there would be named accessors.

[patritzenfeld]

Sounds good.

I had also debated about the current redundancy in the environment, but it seemed to be better to only do the tree normalization once instead of (presumably) on every call of a function accessing the components.