"Pit" in the Robot Framework-Start Process

There is a keyword 'Start process' in the Library 'process'.

(Starts a new process on background)

Note: There is also a keyword 'Start Process' in the Library 'operatingsystem'. But has been abandoned, it is recommended to use Process.Start Process.

= = = This is the part where I found this "pit". Not interested, can jump directly to the end of the text = =

Recently encountered a problem. > Phenomenon :

Note: The system under test (SUT) is a WinForm program, written in C #. Net
When a case is executed, the manual execution is normal , but when executed with the Robot Framework, the SUT is always executed to a fixed step, and then, if you stop Robot framework,sut, you can continue execution, normal end ; the same case does not have this problem when testing a previous version . > by :

When I received this task, I first suspected that the script of case was inappropriate, which led to the affected system being tested.

(after all, manual execution is no problem)

Thus: the keyword that the Robot Framework is executingis studied when the system under test is stuck. No fruit. The keyword (I do it myself): continuously detects whether the system under test has a pop-up message box at a fixed time until the message box pops up or times out. I've also considered whether the uiautomation underlying implementation led to the Robot Framework constantly detecting SUT ui;sut and constantly updating the UI (refreshing various interface effects). Think about the possibility of feeling unlikely, and then consider other reasons. Review The entire case execution line . No fruit. Then use the Exclusion method (semi-automation): Manually start the SUTand perform the next steps automatically . SUT smooth execution of the completed.

So guess is in the script, the way to start SUT caused.

Turn the boot mode from
process.start Process ${sut.exe}

Switch

Evaluate subprocess. Popen ([' ${sut.exe} ']) subprocess

After testing, SUT successfully executed.
In order not to delay testing the business too much time, first use the new scheme, the specific problem causes themselves to study slowly.

Get SUT source code, start debugging .

found that if you start sut,sut with start Process, you will get stuck somewhere when you call Console.WriteLine .

This statement is stuck in a loop and is jammed each time after a fixed number of loops are executed.

At this point the faint feeling is that the output is redirected after the maximum output data limit is encountered.

Then there is a follow-up of some contrasting experiments to validate the idea.

= = = Discovery process ended = = =

process.start Process ${sut.exe}

Vs

Evaluate subprocess. Popen ([' ${sut.exe} ']) subprocess

In fact, the bottom of both calls the subprocess. Popen, but the parameters passed to Popen are different.

The Start process internally assigns some specific default values to the parameters, where the output of the child process is redirected to subprocess. PIPE; the output is redirected to a stream, and there is no reader (unless the user initiates the action), and if the child process continues to write data to the output stream, it will result in more and more data in the stream (not being read out), and the maximum limit is reached, and then the child process is stuck on the next write operation ( cannot be written to).

Some examples on MSDN also have some instructions for this type of deadlock: Process.standardoutput property
Size: 3.9 KB size: 5.5 KB View picture attachments