Handling tests that fork: see only one process as a tests about ward

[darrenburns]

Perhaps I'm misunderstanding but the observed behaviour is what I would expect.

Here's the output explained line by line, from my understanding:

The parent Ward process collects the 1 test:

Ward collected 1 tests in 0.17 seconds.

The fork now happens, meaning there are now two Python processes running Ward, and both parent and child processes refer to the same single test.

The SIGINT is received by the parent process, which cancels the run in that process only. When this happens, the parent process prints the following message to the terminal:

[WARD] Run cancelled - results for tests that ran shown below.

NO_TESTS_FOUND in 1.18 seconds

(The NO_TESTS_FOUND message should probably be NO_TESTS_RUN, because in this case the test was found, but was cancelled before it was run).

The child process is still running at this point, and execution enters the if pid == 0 block, eventually hitting expect(True).equals(True), which results in a passing test. In turn, the child process prints:

 PASS  test_SSH:69: My test that forks                                                                                                                                                        

..............................................................................................................................................................................................
 
SUCCESS in 1.24 seconds [ 1 passed ]

Note that the parent process exits with a non-zero exit code, because from its perspective no tests were run.

I also performed the same test using pytest and got the same outcome:

Do you have a specific use-case for using os.fork in a test?

[drakes00]

I agree that the behavior seems rational given the fork.
I wish I could tell ward to only treat one of the processes in order to only have the right output.
One solution I just though may be to change SIGINT to SIGKILL in order to stop the father's ward. Yet, it feels quite dirty.

The point of the forked test was to run some kind of sockerserver.TCPServer().server_forever() and in parallel, make GET requests. I managed to avoid the fork with some refactoring.

Thanks

[darrenburns]

@drakes00 Glad to hear you managed to sort it.

I don't know what approach you've taken, but for that sort of thing, I'd recommend defining a fixture that starts the server in a separate process (look at multiprocessing module), and tears it down after.

The Teardown Code section of the following page may be useful: https://wardpy.com/guide/fixtures