Saturday, 14 February 2009

Wellington Flex User Group Presentation

I gave a presentation to the Wellington Flex user Group comparing four of the Flex unit testing frameworks (see 16 and 22 November 2008, and 16 December 2008 for some of the comparison results or download the slides). As well as comparing the four frameworks, I presented some examples. The download includes a lot more examples than what I had time to present.

During the discussion, a number of interesting principles in relation to testing were covered.

  1. Test-first programming is about programming with intent. The programmer specifies what they intend the program to do. That is they specify an initial condition or state (given), the action to be performed (when), and the expected result (then). To specify these as executable requirements (tests), they need to have some idea of the design of the code.
  2. When comparing the time to develop using test-first development versus other strategies, the times compared should include both the initial development time and the debug time. If test-first is used then the number of bugs should be reduced and therefore the overall time reduced. I would also contend from my own experience that have the tests or executable requirements helps ensure that I don't introduce bugs into previously completed requirements.
  3. With respect to code coverage for the test-first written code, in theory, the programmer should have 100% cover since they should not write code that their tests do not require. The question isn't whether there is 100% cover of the code by the tests, it is whether the intentions expressed in the tests represent 100% of the requirements. If a requirement is missed then the code won't implement that requirement.
  4. All programmer's already do manual tests of their code based on there understanding of the requirements. The problem is that those tests are manually run and not consistently run. Automated tests ensure that prior tests are run against the code every time there is a change thus ensuring that no requirements are overlooked in testing new code.
  5. To make it easier to use a test-driven approach to coding, consider making the MXML form contain no ActionScript code. Place the ActionScript code in a class that the MXML inherits. This way, the MXML can use the ActionScript code as if it was part of itself. In the ActionScript class set up a model that reflects the key status attributes of the form and bind the MXML properties to the appropriate status elements of the model. The ActionScript class makes no reference to the MXML component. Sorry, I don't have an example that I can make available at present.