There can be instances that might result in incorrect code coverage results due to "truncation".
Local and remote acceptance tests are affected.
The test requests are arriving consecutively on the server and the server starts to process them. Depending on the extend of the tests they might not end in the same order they arrive. So far this is no problem because PR #25 addressed already the read/write collisions.
If a report is requested, either via a route (e.g c3/report/html) or right away from codeception, there is no guarantee that all coverage results are already merged. As a consequence, there can be requests in queue waiting to get access to the locked file to write merged test results along with a read request to create a report. As the order of file access is not guarantee to be the same as the order of incoming server requests, there can be instances where a report is created that lacks some test results due to the fact that they are not merged yet.
A quick and dirty fix is to add a sleep(x) command in a Helper:
<?php declare(strict_types=1);
namespace Helper;
// here you can define custom actions
// all public methods declared in helper class will be available in $I
class MyHelper extends \Codeception\Module
{
// HOOK: after suite
// Wait a bit to merge all coverage results before requesting the reports.
// This will avoid a truncated report.
public function _afterSuite()
{
// time must be adjusted depending on the individual situation
sleep(5);
}
}
Hi,
There can be instances that might result in incorrect code coverage results due to "truncation". Local and remote acceptance tests are affected.
The test requests are arriving consecutively on the server and the server starts to process them. Depending on the extend of the tests they might not end in the same order they arrive. So far this is no problem because PR #25 addressed already the read/write collisions.
If a report is requested, either via a route (e.g
c3/report/html
) or right away from codeception, there is no guarantee that all coverage results are already merged. As a consequence, there can be requests in queue waiting to get access to the locked file to write merged test results along with a read request to create a report. As the order of file access is not guarantee to be the same as the order of incoming server requests, there can be instances where a report is created that lacks some test results due to the fact that they are not merged yet.A quick and dirty fix is to add a
sleep(x)
command in a Helper:I came across this issue in eLabFTW
~I would like to have a better solution but the fix mentioned above is so far the best I have.~ One way to fix this issue is provided in #90.