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.
>
>
