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>
The acceptance tests verify that a Nextcloud server works as expected
from the point of view of an end-user. They are specified as user
stories using Behat paired with Mink, which provides web browser
automation.
Mink supports several browser emulators, but the system is set up to use
Selenium, as it is FOSS and the one that better reflects the use of a
web browser by an end-user (as, in fact, it controls real web browsers).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This allows adding rate limiting via annotations to controllers, as one example:
```
@UserRateThrottle(limit=5, period=100)
@AnonRateThrottle(limit=1, period=100)
```
Would mean that logged-in users can access the page 5 times within 100 seconds, and anonymous users 1 time within 100 seconds. If only an AnonRateThrottle is specified that one will also be applied to logged-in users.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
Add test for basic deletion.
Add test when deleting from shared folder as recipient.
Add test to check that metadata stays when moving out of shared folder
as recipient.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
This helps massively reduce the numerous useless 401 exceptions that
appears in the test log. These appear only because Sabre first connects
without any auth type to receive the challenge and then sends the
authentication data.
With this change it will directly use basic auth.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
There is a bunch of javascript we always load from vendors. This
combines this into 1 javascript file. Which reduces the number of
request by ~10.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
This will help user to selectively move the folders
specified using --path option, instead of moving
entire folder under files directory.
Signed-off-by: Sujith H <sharidasan@owncloud.com>
Update the integration test for transfer-ownership
Update the integration test for transfer-ownership
as the new option --path is introduced in the command.
Signed-off-by: Sujith H <sharidasan@owncloud.com>
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
Add test for basic deletion.
Add test when deleting from shared folder as recipient.
Add test to check that metadata stays when moving out of shared folder
as recipient.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>