On 2 July 2010 21:43, [email protected] <[email protected]> wrote:
> >>The thought of having third party software clicking all over a winforms > app gives me the creeps. > > Why should it? IMO it's a good thing. The idea is to try and break the > code before your customers do. > A few years back I put AutoMate ( > http://www.networkautomation.com/automate/7/) to a lot of use running > tests on my winforms code (clinical applications). At the time I also had to > build stuff in CA Visual Objects which only had an IDE and no command line > compiler. I had the AutoMate scripts drive the compiler and produce builds, > and check the text on the status line for compilation results. This saved a > lot of time and made it more conducive to running a build more often. > > I can appreciate that in a scenario where it is not possible to directly simulate the user interface in code, you might want have a test harness actually use the UI. The downside is that the coupling between your testing code and the user interface is brittle. What happens if the window size changes, a button is renamed/moved, tab order changes, one form is refactored into two? In each case the test harness will break and you need to adjust it to cope with the changed UI. I acknowledge that some of the same problems are present when you simulate your UI directly in code, and the UI changes. However you will know about it sooner via a compiler error. All your testing code benefits from strong typing and refactoring support in the IDE. > That really helps shake bugs out of your software. Unit tests are great too > but there is definitely a place for these sorts of external UI-exercisers. > > Fair point, I can see the value in having some external UI-exerciser used in conjunction with unit tests. I would limit the use however to basic scenarios such as "Is the form showing without error" and leave the complicated scenarios to unit tests and code, unless I had plenty of manpower to keep the scripts up to date.
