If you are developing a complicated algorithm, it helps if you develop testcases as you go to drive the development and to make sure that the things that used to work still work after you make changes. It's hard, however, to write those testcases when you're developing new user interface components. I was in this situation recently when I was developing a new user interface layout technique called Fluid Positioning. In this feature, user interface widgets would be placed, resized, and moved on the user interface in response to mouse movements. I deemed it too difficult to test with automated testing and resorted to manual testing of the code. After getting into the project, however, I found that I was getting the classic "Wack a Mole" problem where I fix a problem in one spot only to have several other problems pop up in other spots. I wouldn't realize these other problems were there until much later when it was more difficult to fix. In the end, I developed a testing framework that would open a window to a fixed size, allow me to test the code by simulating mouse clicks and mouse movements, check the layouts of the widgets on the window, and automatically close the window at the end of the test. I could then run regression tests on the system to make sure all the existing code still worked. This framework completely changed my development style. I immediately switched to a test-driven mode where I required a failing testcase before making any changes and once I made a change I made sure all testcases passed before moving on. The framework required an investment in time and effort to develop but it paid for itself in the stability and reliability of the resulting code.
Download