Is this software created by Microsoft ..i have found Test Manager by a company called Ekobit?
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Peter Gfader Sent: Tuesday, 6 July 2010 1:37 AM To: ozDotNet Subject: Re: UI Automation Testing Software for Win Forms I had very good experience on using MS Test Manager for automating Windows Forms Applications in conjunction with generating Coded UI tests: + The code that the MTM produces is nice to read + The code is easy to change, because of readability + Small UI changes -> no need to change the test + button name change no problem + tab order change depends from test code + window size no problem generally - form is refactored into two means, test re-record and generate (which is easy, once you're used to) - Slow execution of the tests (in comparison to unit tests) because of the nature of UI tests - Setup of application can be a bit painful... .peter.gfader. http://blog.gfader.com/ http://twitter.com/peitor On Mon, Jul 5, 2010 at 2:44 AM, Alan Heywood <a...@heywood.id.au> wrote: On 2 July 2010 21:43, ste...@malikoff.com <ste...@malikoff.com> 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.
