Problem: Developing a reliable test runner for your automation takes time. At Qxf2, we would rather spend our time improving the quality of the tests and making automated checks more robust. This post will show you a quick way to develop a test runner on Windows.
Testing teams usually have many automated test scripts that execute one after the other. A test runner executes the tests you want one after the other. Here is perhaps the quickest way to do so on Windows:
1. Gather your test scripts
2. Create a batch script
3. Create a scheduled task
For the purposes of this example, we’ll use two dummy scripts that take in command line arguments and execute them.
STEP 1: Gather your scripts
At Qxf2, Python is our language of choice. For this example, I’ve written up two throwaway script that will take a string as an input parameter and print out the string 10 times over 10 seconds.
STEP 2: Create a batch script
Create a batch script that looks like below. For batch scripting newbies:
– %1 is used for the first command line argument you pass to the batch script
– in this case we will pass the directory where our test scripts are located
– :: is used for comments
You can test your batch script by opening up a command prompt, changing your directory to where the batch script is located and running it. If you are using the example provided here, you would run something like:
>> sample_bat path_to_the_python_test_scripts
STEP 3: Create a scheduled task
Scheduled tasks on Windows are like cron jobs on Unix based systems. There are many good tutorials on creating scheduled tasks on Windows. The summary is that you create a basic task and schedule it to run with the frequency that you like. Just make sure that your task Action is configured to look like the screenshot below.
You can test your scheduled task by right clicking on it in the task scheduler and selecting ‘Run’.
As and when you develop new tests, you can add them to the batch script. There you have it – a lightweight test runner on Windows.
As with all technical solutions, the use of this technique depends on your current context.
Some situations to use this technique are:
– in early stages of introducing automation in your company
– you want to get nightly automation going as soon as possible
– in ambitious, tight schedules that leave little time for developing QA infrastructure
– the project demands a lightweight solution
Some situations where you should NOT to use this technique?
– you have the budget to invest on QA infrastructure
– the complexity of your automation suite requires a heavyweight solution