Automation best practices

[Bert]

This is my list of do's and don't when automating an application using AutoIt.

1. You should always write out a pseudo script defining what you want to do BEFORE you write any code. The best way to define what you are doing is document your steps you do manually. Keep it simple.

2. Hooking into controls for non- web based applications: In many cases the basic AutoIt commands will work fine. If not then this will work: https://www.autoitscript.com/forum/topic/153520-iuiautomation-ms-framework-automate-chrome-ff-ie/

3. If you are working with a web based application you can use IE.au3 or take a look at this: https://www.autoitscript.com/forum/topic/153520-iuiautomation-ms-framework-automate-chrome-ff-ie/

4. Pixel searching: It should NEVER be used unless there is no other option (and all other methods have been tried first to hook into the control in question). The reasons being are many:

• If the pixel gets moved for some reason - your script breaks.
• window resized - script breaks
• pixel color is changed due to the app being updated in some manner - script breaks
• it is slow for for some cases you may have to search a large area.

5. Command line switches - if you are dealing with a package you wish to install and you wish to automate it - look to see if the package supports command line switches. This can make a multi-line script a simple one line script and make your installs much more stable.

6. Script stability: What this basically means is you account for possible failures that may occur when your script runs. For example if your script is waiting for a window to gain focus, you may want to put in a time out or an alert if the window fails to appear. There are many options that one can do for this sort of thing. If you are not sure on what to do, ask in the forum and another member can make a few suggestions for you.

7. The AutoIt help file is your friend. For just about every command there is an example and you have a search function in the help file. USE IT! If you can't find what you need there then look in the forum and use the forum's search function FIRST before posting a question.

8. When you run into trouble with your script: Post it in the Help and support section of the AutoIt forum so we can help you.

Edited December 28, 2016 by Bert

[junkew]

Additions using about 20 years all kinds of testautomation tools

Point 1 define a specification language that is executable by humans but also by tooling interpreter

Point 2 offcourse i wrote it

Point 4 although its technically harder to maintain its the only solution that really is equal to a human tester

http://www.t-plan.com/robot/

http://www.sikuli.org

9. Build a framework.

Split functional description from the executing tool as overtime your automation tool probably will change.

Logger functions like log4j

Data functions for managing testdata

10. Frameworks

Record and playback

Function _ module driven

Keyword driven

Datadriven

Hybrid

Bdd tdd gherkin driven

Model based