server/tests/acceptance/features/core/Utils.php

91 lines
3.3 KiB
PHP
Raw Normal View History

Add helper context to isolate the test server with Docker containers Scenarios in acceptance tests must be independent one of each other. That is, the execution of one scenario can not affect the execution of another scenario, nor it can depend on the result of the execution of a different scenario. Each scenario must be isolated and self-contained. As the acceptance tests are run against a Nextcloud server the server must be in a known and predefined initial state each time a scenario begins. The NextcloudTestServerContext is introduced to automatically set up the Nextcloud test server for each scenario. This can be achieved using Docker containers. Before an scenario begins a new Docker container with a Nextcloud server is run; the scenario is then run against the server provided by the container. When the scenario ends the container is destroyed. As long as the Nextcloud server uses local data storage each scenario is thus isolated from the rest. The NextcloudTestServerContext also notifies its sibling RawMinkContexts about the base URL of the Nextcloud test server being used in each scenario. Although it uses the Behat context system, NextcloudTestServerContext is not really part of the acceptance tests, but a provider of core features needed by them; it can be seen as part of a Nextcloud acceptance test library. Therefore, those classes are stored in the "core" directory instead of the "bootstrap" directory. Besides its own (quite limited) autoload configuration, Behat also uses the Composer autoloader, so the "core" directory has to be added there for its classes to be found by Behat. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2017-04-04 14:11:34 +00:00
<?php
/**
*
* @copyright Copyright (c) 2017, Daniel Calviño Sánchez (danxuliu@gmail.com)
*
* @license GNU AGPL version 3 or any later version
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU Affero General Public License as
* published by the Free Software Foundation, either version 3 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Affero General Public License for more details.
*
* You should have received a copy of the GNU Affero General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*
*/
class Utils {
/**
* Waits at most $timeout seconds for the given condition to be true,
* checking it again every $timeoutStep seconds.
*
* Note that the timeout is no longer taken into account when a condition is
* met; that is, true will be returned if the condition is met before the
* timeout expires, but also if it is met exactly when the timeout expires.
* For example, even if the timeout is set to 0, the condition will be
* checked at least once, and true will be returned in that case if the
* condition was met.
*
* @param \Closure $conditionCallback the condition to wait for, as a
* function that returns a boolean.
* @param float $timeout the number of seconds (decimals allowed) to wait at
* most for the condition to be true.
* @param float $timeoutStep the number of seconds (decimals allowed) to
* wait before checking the condition again.
* @return boolean true if the condition is met before (or exactly when) the
* timeout expires, false otherwise.
*/
public static function waitFor($conditionCallback, $timeout, $timeoutStep) {
$elapsedTime = 0;
$conditionMet = false;
while (!($conditionMet = $conditionCallback()) && $elapsedTime < $timeout) {
usleep($timeoutStep * 1000000);
$elapsedTime += $timeoutStep;
}
return $conditionMet;
}
/**
* Waits at most $timeout seconds for the server at the given URL to be up,
* checking it again every $timeoutStep seconds.
*
* Note that it does not verify whether the URL returns a valid HTTP status
* or not; it simply checks that the server at the given URL is accessible.
*
* @param string $url the URL for the server to check.
* @param float $timeout the number of seconds (decimals allowed) to wait at
* most for the server.
* @param float $timeoutStep the number of seconds (decimals allowed) to
* wait before checking the server again; by default, 0.5 seconds.
* @return boolean true if the server was found, false otherwise.
*/
public static function waitForServer($url, $timeout, $timeoutStep = 0.5) {
$isServerUpCallback = function() use ($url) {
$curlHandle = curl_init($url);
// Returning the transfer as the result of curl_exec prevents the
// transfer from being written to the output.
curl_setopt($curlHandle, CURLOPT_RETURNTRANSFER, true);
$transfer = curl_exec($curlHandle);
curl_close($curlHandle);
return $transfer !== false;
};
return self::waitFor($isServerUpCallback, $timeout, $timeoutStep);
}
Add helper context to isolate the test server with Docker containers Scenarios in acceptance tests must be independent one of each other. That is, the execution of one scenario can not affect the execution of another scenario, nor it can depend on the result of the execution of a different scenario. Each scenario must be isolated and self-contained. As the acceptance tests are run against a Nextcloud server the server must be in a known and predefined initial state each time a scenario begins. The NextcloudTestServerContext is introduced to automatically set up the Nextcloud test server for each scenario. This can be achieved using Docker containers. Before an scenario begins a new Docker container with a Nextcloud server is run; the scenario is then run against the server provided by the container. When the scenario ends the container is destroyed. As long as the Nextcloud server uses local data storage each scenario is thus isolated from the rest. The NextcloudTestServerContext also notifies its sibling RawMinkContexts about the base URL of the Nextcloud test server being used in each scenario. Although it uses the Behat context system, NextcloudTestServerContext is not really part of the acceptance tests, but a provider of core features needed by them; it can be seen as part of a Nextcloud acceptance test library. Therefore, those classes are stored in the "core" directory instead of the "bootstrap" directory. Besides its own (quite limited) autoload configuration, Behat also uses the Composer autoloader, so the "core" directory has to be added there for its classes to be found by Behat. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2017-04-04 14:11:34 +00:00
}