Test automation using batch files:

I have the following layout for my test suite:

TestSuite1.cmd:

1. Run my program
2. Check its return result
3. If the return result is not 0, convert the error to textual output and abort the script. If it succeeds, write out success.

In my single .cmd file, I call my program about 10 times with different input.

The problem is that the program that I run 10 times takes several hours to run each time.

Is there a way for me to parallelize all of these 10 runnings of my program while still somehow checking the return result and providing a proper output file and while still using a single .cmd file and to a single output file?

From stackoverflow Brian R. Bondy

• try the command start, it spawns a new command prompt and you can send along any commands you want it to run.

  I'd use this to spawn batch files that run the tests and then appends to a output.txt using >> as such:

  testthingie.cmd >> output.txt
  

  Brian R. Bondy : but this doesn't solve my problem, I still want to check and write output to a single output file.
  From grapefrukt

• Running things in parallel in batch files can be done via 'start' executable/command.

  From Iulian Şerbănoiu

• Assuming they won't interfere with each other by writing to the same files,etc:

  test1.cmd

  :: intercept sub-calls.
    if "%1"=="test2" then goto :test2
  
  :: start sub-calls.
    start test1.cmd test2 1
    start test1.cmd test2 2
    start test1.cmd test2 3
  
  :: wait for sub-calls to complete.
  :loop1
    if not exist test2_1.flg goto :loop1
  :loop2
    if not exist test2_2.flg goto :loop2
  :loop3
    if not exist test2_3.flg goto :loop3
  
  :: output results sequentially
    type test2_1.out >test1.out
      del /s test2_1.out
      del /s test2_1.flg
    type test2_2.out >test1.out
      del /s test2_2.out
      del /s test2_2.flg
    type test2_3.out >test1.out
      del /s test2_3.out
      del /s test2_3.flg
  
    goto :eof
  :test2
  
  :: Generate one output file
    echo %1 >test2_%1.out
    ping -n 31 127.0.0.1 >nul: 2>nul:
  
  :: generate flag file to indicate finished
    echo x >test2_%1.flg
  

  This will start three concurrent processes each which echoes it's sequence number then wait 30 seconds.

  All with one cmd file and (eventually) one output file.

  Brian R. Bondy : What if test1 takes longer than test2 sometimes?

  paxdiablo : This one will start all three but the main program will be responsible for gathering the individual outputs - flag files are used to indicate to main program that sub-program has finished.

  paxdiablo : Timing won't matter in this version - it'll wait until all concurrent sub-programs are finished before the main program collates the output files. The whole process will only take as long as the longest sub-program (with a little extra for collation).

  Brian R. Bondy : That's great, thanks for the help!

  Adam Liss : Brilliant! This is an excellent tutorial in creative batch file use, and its skeleton works for any batch file that must orchestrate several activities. Any CPU-hogging issues with the tight goto loops--perhaps a "ping delay" here?
  From paxdiablo

• Windows:

  you create a Batch File that essentially calls:

  start TestSuite1.cmd [TestParams1]
  start TestSuite1.cmd [TestParams2]
  

  and so on, which is essentially forking new command lines,

  which would work, if the application can handle concurrent users (even if its the same User), and your TestSuite1.cmd is able to handle parameters.

  Brian R. Bondy : How to nicely do an output file in this case though?

  Brian R. Bondy : I want some way to display success or failed for each result.

  paxdiablo : This doesn't do it in a single command file.
  From Martin

• You will need to start the script with different parameters on different machines because whatever makes the program take so long for a task (IO, CPU time) will be in even shorter supply when multiple instances of your program run at once.

  Only exception: the run time is cause by the program putting itself to sleep.

  paxdiablo : I/O can be overlapped, that's why things can run in parallel faster than sequentially - obviously that's not the case if you're CPU-bound.
  From xmjx