*Hi* Microsoft Test Manager is part of Visual Studio 2010 Ultimate
Comparison of different editions can be found here http://www.microsoft.com/visualstudio/en-us/products .peter.gfader. http://blog.gfader.com/ http://twitter.com/peitor On Tue, Jul 6, 2010 at 1:46 AM, Anthony <[email protected]> wrote: > Is this software created by Microsoft ..i have found Test Manager by a > company called Ekobit? > > > > *From:* [email protected] [mailto: > [email protected]] *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 <[email protected]> wrote: > > > > 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. > > > > >
