From my experience whatever you do in Sprint 1 dictates the success of your project. If you opt for a running start and ignore practices such as TDD, Pair Programming, Automation, and Refactoring then your velocity won’t account for them. You face a similar challenge if you have a herculean Sprint 1. Whatever you do sets an expectation with the customer – the velocity achieved in Sprint 1 sets an expectation of what can be achieved in future Sprints. It is incredibly difficult to reset that expectation as your velocity will dip if you decided to start Refactoring or doing TDD or working a 40 hour week.
As professionals we have a responsibility to write clean code from the start. The customer may feel we are moving slowly but we are investing in the future maintainability of the software. Through TDD we are building testable software and providing the team with the confidence to Refactor. In turn Refactoring allows us to evolve our design so they remains simple. The story is similar for the other practices of professional software engineering.
As the software grows the teams has pride in the software they are engineering. The quality is high and its easy to change the software as new requirements are implemented. In the end customer satisfaction is high, why wouldn’t you practice TDD and Refactoring from day-1?
I recently read a blog post from Mike Cohn on “The Forgotten Layer of the Test Automation Pyramid”:http://blog.mountaingoatsoftware.com/the-forgotten-layer-of-the-test-automation-pyramid. I thought this was a great way to conceptualize the different forms of testing and their combined value.
Last year I blogged about XDoclet2 and FlexUnit and Ant . In this entry I am going to look at setting up CruiseControl for continuous integration. I have setup my CruiseControl server on Linux so I will do my best to make sure these instruction also apply to Windows. I also used Perforce as my source control repository so I have included the extra steps that are required to get CruiseControl working with Perforce. CruiseControl supports many other repositories such as Subversion and CVS. Please refer the the CuriseControl configuration reference for more details.
You can download a new release of FlexUnit for Ant. This version fixes a bug with the toDir property and also removes the need to create a configuration file under the FlashPlayerTrust folder to allow the SWF to run in the local trusted sandbox. The Ant task will now send a policy file to the Flash Player to allow the data to be sent over the socket – should make life a little easier.
For more details on how to use FlexUnit for Ant please see my earlier blog. There is also documentation on the flexunit Ant task parameters at the end of this blog. You can download FlexUnit from Adobe Labs.
You can download a new release of FlexUnit for Ant, which fixes a few bugs people have experienced recently. For more details on how to use FlexUnit for Ant please see my earlier blog. There is also documentation on the flexunit Ant task parameters at the end of this blog. You can download FlexUnit from Adobe Labs.
Many thanks to Tony Hillerson of EUI for his contribution following my last blog on FlexUnit + Ant. Tony has taken the FlexUnit task and added the following properties:
- haltonfailure – stop the build process if a failure occurs in one of the tests..
- failureproperty – the name of a property to set if there is a failure in one of the tests..
- verbose – print information about the test run.
I have been planning this blog for some time, but was spurred on by a recent blog on Continous Integration in Flex. This blog concentrates on integration between Ant and FlexUnit, I will post a follow-up entry with details on how to setup a CruiseControl server for Continuous Integration.