1

I am writing a Test Automation Framework that involves automating testing a Winforms and WPF based application having 200 screens. The Automation Framework should do the control clicks and screen actions just as a tester would do to test a case by manually clicking the controls on the screens.

The Framework can change only when one of the following happens:

  1. New screens and functionalities are added.
  2. Existing screens are modified (UI).
  3. Existing screen functionalities are modified. For example, changing a ListView to a GridView to show data on a button click.
  4. Changes in business rules.

I am new to patterns, and am learning. Based on these requirements, can someone please tell me what patterns may prove most useful (if at all) is writing this fraemwork?

linuxbuild
  • 15,843
  • 6
  • 60
  • 87
techjourneyman
  • 1,701
  • 3
  • 33
  • 53
  • If you do not want to hear answer 'Use at least 4 GoF patterns' then you should ask more specific question. Maybe asking about some well-defined subsystem will be more successful. – Snowbear Feb 14 '11 at 15:35
  • stop it, right there! don't try applying a pattern somewhere where it does not belong. Patterns are for solving specific problems. And here you don't have a specific problem - you need to write tests. Learn to write tests for your app, patterns will come when you actually need them. It is good to know them so you can use them. But don't put a pattern everywhere! – trailmax Jun 22 '14 at 00:43

3 Answers3

3

Snowbear is correct above...some specifics would help. But it seems pretty obvious that you'd be using the Command and Decorator patterns, for sure.

Just keep in mind - patterns are battlefield tactics, not laws. They need to be adjusted to fit the battlefield. I had to overcome a tendency to be legalistic about using them when I learned them.

Chris B. Behrens
  • 6,255
  • 8
  • 45
  • 71
1

I am not sure you will accept this as an answer but here goes:

Don't write a framework. Put effort in finding and experimenting with existing testing tools. WPF UI testing is very different from WinForms testing. Patterns are the least of your worries.

EDIT Have a look at these posts:

  1. WinForms
  2. WPF
Community
  • 1
  • 1
Emond
  • 50,210
  • 11
  • 84
  • 115
0

Before you attempt to list all the patterns you need, you should design a higher level architecture for the application. Just from the description I guess you would need some sort of "form parsing" or "component mapping" which will be passed to an "actor" which will carry out actions associated with the components (e.g. click, insert text). At the end the form is submitted to the audition system. This is obviously my way of doing it, probably there is a better way.

Ricardo Ferreira
  • 766
  • 5
  • 15