nextcloud/tests/acceptance/features/bootstrap/FilesAppContext.php

464 lines
15 KiB
PHP
Raw Normal View History

<?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/>.
*
*/
use Behat\Behat\Context\Context;
class FilesAppContext implements Context, ActorAwareInterface {
use ActorAware;
use FileListAncestorSetter;
/**
* @return array
*/
public static function sections() {
return [ "All files" => "files",
"Recent" => "recent",
"Favorites" => "favorites",
"Shared with you" => "sharingin",
"Shared with others" => "sharingout",
"Shared by link" => "sharinglinks",
"Tags" => "systemtagsfilter",
"Deleted files" => "trashbin" ];
}
/**
* @return Locator
*/
public static function mainViewForSection($section) {
$sectionId = self::sections()[$section];
return Locator::forThe()->id("app-content-$sectionId")->
describedAs("Main view for section $section in Files app");
}
/**
* @return Locator
*/
public static function currentSectionMainView() {
return Locator::forThe()->xpath("//*[starts-with(@id, 'app-content-') and not(contains(concat(' ', normalize-space(@class), ' '), ' hidden '))]")->
describedAs("Current section main view in Files app");
}
/**
* @return Locator
*/
public static function detailsView() {
return Locator::forThe()->id("app-sidebar")->
describedAs("Details view in Files app");
}
Solve acceptance test failure due to clicks on covered elements Firefox and Chrome drivers for Selenium refuse to click on an element if the point to be clicked is covered by a different element, throwing an UnknownError exception with message "Element is not clickable at point ({x}, {y}). Other element would receive the click: {element}". Although in general that would be a legit error (as the user would not be able to click on the element) due to a bad layout, sometimes this can be just a temporal issue caused by an animation, in which case there would be no problem once the animation finished and the elements are all in their final location. Unfortunately, automatically handling those situations in which the problem is caused by an animation by just retrying a few times if the element to be clicked is covered before giving up would probably cause confusion instead of easing test writing. The reason is that if the center of the element is covered by another one the Firefox driver for Selenium tries to click on the corners of the element instead. The problem is that the coordinates used for the click are integer values, but Firefox has sub-pixel accuracy, so sometimes (depending on which corner is not covered and whether the left, top, width or height properties of the element to be clicked have a decimal component or not) the clicks silently land on a different HTML element (and that is with squared borders; with round borders they always land on a different HTML element. That was partially addressed for Selenium 3.0 by clicking first on the edges, but it would still fail if the middle point of the edges is covered but not the corners). It is not possible to fix or even detect all that from the tests (except maybe with some extreme hacks involving accessing private PHP members from Mink and bypassing or replacing the standard JavaScript executed by the Firefox driver with a custom implementation...), so it is not possible to ensure that clicks during an animation will land on the right element (in fact it is not possible even on static elements, although except when the layout is wrong there should be no problem); sometimes retrying a click when the element is covered would solve the problem, sometimes it would cause a different element to be clicked (and sometimes there would be even no retry, as the first click would have silently landed on a different element than the expected one). Therefore, a different approach must be used. Instead of trying to automatically handle clicks during animations the tests must be written being aware of the problem and thus waiting somehow for the animations that can cause a problem to end before performing the clicks. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2017-10-18 15:00:32 +03:00
/**
* @return Locator
*/
public static function closeDetailsViewButton() {
return Locator::forThe()->css(".icon-close")->
descendantOf(self::detailsView())->
describedAs("Close details view in Files app");
Solve acceptance test failure due to clicks on covered elements Firefox and Chrome drivers for Selenium refuse to click on an element if the point to be clicked is covered by a different element, throwing an UnknownError exception with message "Element is not clickable at point ({x}, {y}). Other element would receive the click: {element}". Although in general that would be a legit error (as the user would not be able to click on the element) due to a bad layout, sometimes this can be just a temporal issue caused by an animation, in which case there would be no problem once the animation finished and the elements are all in their final location. Unfortunately, automatically handling those situations in which the problem is caused by an animation by just retrying a few times if the element to be clicked is covered before giving up would probably cause confusion instead of easing test writing. The reason is that if the center of the element is covered by another one the Firefox driver for Selenium tries to click on the corners of the element instead. The problem is that the coordinates used for the click are integer values, but Firefox has sub-pixel accuracy, so sometimes (depending on which corner is not covered and whether the left, top, width or height properties of the element to be clicked have a decimal component or not) the clicks silently land on a different HTML element (and that is with squared borders; with round borders they always land on a different HTML element. That was partially addressed for Selenium 3.0 by clicking first on the edges, but it would still fail if the middle point of the edges is covered but not the corners). It is not possible to fix or even detect all that from the tests (except maybe with some extreme hacks involving accessing private PHP members from Mink and bypassing or replacing the standard JavaScript executed by the Firefox driver with a custom implementation...), so it is not possible to ensure that clicks during an animation will land on the right element (in fact it is not possible even on static elements, although except when the layout is wrong there should be no problem); sometimes retrying a click when the element is covered would solve the problem, sometimes it would cause a different element to be clicked (and sometimes there would be even no retry, as the first click would have silently landed on a different element than the expected one). Therefore, a different approach must be used. Instead of trying to automatically handle clicks during animations the tests must be written being aware of the problem and thus waiting somehow for the animations that can cause a problem to end before performing the clicks. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2017-10-18 15:00:32 +03:00
}
/**
* @return Locator
*/
public static function fileNameInDetailsView() {
return Locator::forThe()->css(".fileName")->
descendantOf(self::detailsView())->
describedAs("File name in details view in Files app");
}
/**
* @return Locator
*/
public static function fileDetailsInDetailsViewWithText($fileDetailsText) {
return Locator::forThe()->xpath("//span[normalize-space() = '$fileDetailsText']")->
descendantOf(self::fileDetailsInDetailsView())->
describedAs("File details with text \"$fileDetailsText\" in details view in Files app");
}
/**
* @return Locator
*/
private static function fileDetailsInDetailsView() {
return Locator::forThe()->css(".file-details")->
descendantOf(self::detailsView())->
describedAs("File details in details view in Files app");
}
/**
* @return Locator
*/
public static function inputFieldForTagsInDetailsView() {
return Locator::forThe()->css(".systemTagsInfoView")->
descendantOf(self::detailsView())->
describedAs("Input field for tags in details view in Files app");
}
/**
* @return Locator
*/
public static function itemInInputFieldForTagsInDetailsViewForTag($tag) {
return Locator::forThe()->xpath("//span[normalize-space() = '$tag']")->
descendantOf(self::inputFieldForTagsInDetailsView())->
describedAs("Item in input field for tags in details view for tag $tag in Files app");
}
/**
* @return Locator
*/
public static function itemInDropdownForTag($tag) {
return Locator::forThe()->xpath("//*[contains(concat(' ', normalize-space(@class), ' '), ' select2-result-label ')]//span[normalize-space() = '$tag']/ancestor::li")->
descendantOf(self::select2Dropdown())->
describedAs("Item in dropdown for tag $tag in Files app");
}
/**
* @return Locator
*/
public static function checkmarkInItemInDropdownForTag($tag) {
return Locator::forThe()->css(".checkmark")->
descendantOf(self::itemInDropdownForTag($tag))->
describedAs("Checkmark in item in dropdown for tag $tag in Files app");
}
/**
* @return Locator
*/
private static function select2Dropdown() {
return Locator::forThe()->css("#select2-drop")->
describedAs("Select2 dropdown in Files app");
}
/**
* @return Locator
*/
public static function tabHeaderInDetailsViewNamed($tabHeaderName) {
return Locator::forThe()->xpath("//li[normalize-space() = '$tabHeaderName']")->
descendantOf(self::tabHeadersInDetailsView())->
describedAs("Tab header named $tabHeaderName in details view in Files app");
}
/**
* @return Locator
*/
private static function tabHeadersInDetailsView() {
return Locator::forThe()->css(".tabHeaders")->
descendantOf(self::detailsView())->
describedAs("Tab headers in details view in Files app");
}
/**
* @return Locator
*/
public static function tabInDetailsViewNamed($tabName) {
return Locator::forThe()->xpath("//div[@id=//*[contains(concat(' ', normalize-space(@class), ' '), ' tabHeader ') and normalize-space() = '$tabName']/@data-tabid]")->
descendantOf(self::detailsView())->
describedAs("Tab named $tabName in details view in Files app");
}
/**
* @return Locator
*/
public static function loadingIconForTabInDetailsViewNamed($tabName) {
return Locator::forThe()->css(".loading")->
descendantOf(self::tabInDetailsViewNamed($tabName))->
describedAs("Loading icon for tab named $tabName in details view in Files app");
}
/**
* @return Locator
*/
public static function shareLinkCheckbox() {
Remove "content" locator from acceptance tests The "content" locator uses the "named" Mink selector and the "content" Mink locator to find the element. The "named" Mink first tries to find the elements whose content match exactly the given content but, if none is found, then it tries to find elements that just contain the given content. This behaviour can lead to hard to track issues. Finding the exact match and, if not found, finding the partial match is done in quick succession. In most cases, when looking for an exact match the element is already there, it is returned, and everything works as expected. Or it may not be there, but then it is not there either when finding the partial match, so no element is returned, and everything works as expected (that is, the actor tries to find again the element after some time). However, it can also happen that when looking for an exact match there is no element yet, but it appears after trying to find the exact match but before trying to find the partial match. In that situation the desired element would be returned along with its ancestors. However, as only the first found element is taken into account and the ancestors would appear first the find action would be successful, but the returned element would not be the expected one. This is highly unlikely, yet possible, and can cause sporadic failures in acceptance tests that, apparently, work as expected. Using a "named_exact" Mink selector instead of the "named" Mink selector does not provide the desired behaviour in most cases either. As it finds any element whose content matches exactly the given content, looking for "Hello world" in "<div><p><a>Hello world</a></p></div>" would match the "div", "p" and "a" elements; in that situation the "div" element would be the one returned, when typically the "a" element would be the expected one. As it is error prone and easily replaceable by more robust locators the "content" locator was removed from the predefined ones (although it can still be used if needed through the "customSelector" method in the builder object). Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2017-05-02 13:49:27 +03:00
// forThe()->checkbox("Share link") can not be used here; that would
// return the checkbox itself, but the element that the user interacts
// with is the label.
return Locator::forThe()->xpath("//label[normalize-space() = 'Share link']")->
descendantOf(self::detailsView())->
describedAs("Share link checkbox in the details view in Files app");
}
/**
* @return Locator
*/
public static function shareLinkField() {
return Locator::forThe()->css(".linkText")->descendantOf(self::detailsView())->
describedAs("Share link field in the details view in Files app");
}
/**
* @return Locator
*/
public static function allowUploadAndEditingRadioButton() {
// forThe()->radio("Allow upload and editing") can not be used here;
// that would return the radio button itself, but the element that the
// user interacts with is the label.
return Locator::forThe()->xpath("//label[normalize-space() = 'Allow upload and editing']")->
descendantOf(self::detailsView())->
describedAs("Allow upload and editing radio button in the details view in Files app");
}
/**
* @return Locator
*/
public static function passwordProtectCheckbox() {
Remove "content" locator from acceptance tests The "content" locator uses the "named" Mink selector and the "content" Mink locator to find the element. The "named" Mink first tries to find the elements whose content match exactly the given content but, if none is found, then it tries to find elements that just contain the given content. This behaviour can lead to hard to track issues. Finding the exact match and, if not found, finding the partial match is done in quick succession. In most cases, when looking for an exact match the element is already there, it is returned, and everything works as expected. Or it may not be there, but then it is not there either when finding the partial match, so no element is returned, and everything works as expected (that is, the actor tries to find again the element after some time). However, it can also happen that when looking for an exact match there is no element yet, but it appears after trying to find the exact match but before trying to find the partial match. In that situation the desired element would be returned along with its ancestors. However, as only the first found element is taken into account and the ancestors would appear first the find action would be successful, but the returned element would not be the expected one. This is highly unlikely, yet possible, and can cause sporadic failures in acceptance tests that, apparently, work as expected. Using a "named_exact" Mink selector instead of the "named" Mink selector does not provide the desired behaviour in most cases either. As it finds any element whose content matches exactly the given content, looking for "Hello world" in "<div><p><a>Hello world</a></p></div>" would match the "div", "p" and "a" elements; in that situation the "div" element would be the one returned, when typically the "a" element would be the expected one. As it is error prone and easily replaceable by more robust locators the "content" locator was removed from the predefined ones (although it can still be used if needed through the "customSelector" method in the builder object). Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2017-05-02 13:49:27 +03:00
// forThe()->checkbox("Password protect") can not be used here; that
// would return the checkbox itself, but the element that the user
// interacts with is the label.
return Locator::forThe()->xpath("//label[normalize-space() = 'Password protect']")->
descendantOf(self::detailsView())->
describedAs("Password protect checkbox in the details view in Files app");
}
/**
* @return Locator
*/
public static function passwordProtectField() {
return Locator::forThe()->css(".linkPassText")->descendantOf(self::detailsView())->
describedAs("Password protect field in the details view in Files app");
}
/**
* @return Locator
*/
public static function passwordProtectWorkingIcon() {
return Locator::forThe()->css(".linkPass .icon-loading-small")->descendantOf(self::detailsView())->
describedAs("Password protect working icon in the details view in Files app");
}
Solve acceptance test failure due to clicks on covered elements Firefox and Chrome drivers for Selenium refuse to click on an element if the point to be clicked is covered by a different element, throwing an UnknownError exception with message "Element is not clickable at point ({x}, {y}). Other element would receive the click: {element}". Although in general that would be a legit error (as the user would not be able to click on the element) due to a bad layout, sometimes this can be just a temporal issue caused by an animation, in which case there would be no problem once the animation finished and the elements are all in their final location. Unfortunately, automatically handling those situations in which the problem is caused by an animation by just retrying a few times if the element to be clicked is covered before giving up would probably cause confusion instead of easing test writing. The reason is that if the center of the element is covered by another one the Firefox driver for Selenium tries to click on the corners of the element instead. The problem is that the coordinates used for the click are integer values, but Firefox has sub-pixel accuracy, so sometimes (depending on which corner is not covered and whether the left, top, width or height properties of the element to be clicked have a decimal component or not) the clicks silently land on a different HTML element (and that is with squared borders; with round borders they always land on a different HTML element. That was partially addressed for Selenium 3.0 by clicking first on the edges, but it would still fail if the middle point of the edges is covered but not the corners). It is not possible to fix or even detect all that from the tests (except maybe with some extreme hacks involving accessing private PHP members from Mink and bypassing or replacing the standard JavaScript executed by the Firefox driver with a custom implementation...), so it is not possible to ensure that clicks during an animation will land on the right element (in fact it is not possible even on static elements, although except when the layout is wrong there should be no problem); sometimes retrying a click when the element is covered would solve the problem, sometimes it would cause a different element to be clicked (and sometimes there would be even no retry, as the first click would have silently landed on a different element than the expected one). Therefore, a different approach must be used. Instead of trying to automatically handle clicks during animations the tests must be written being aware of the problem and thus waiting somehow for the animations that can cause a problem to end before performing the clicks. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2017-10-18 15:00:32 +03:00
/**
* @Given I close the details view
*/
public function iCloseTheDetailsView() {
$this->actor->find(self::closeDetailsViewButton(), 10)->click();
}
/**
* @Given I open the input field for tags in the details view
*/
public function iOpenTheInputFieldForTagsInTheDetailsView() {
$this->actor->find(self::fileDetailsInDetailsViewWithText("Tags"), 10)->click();
}
/**
* @Given I open the :tabName tab in the details view
*/
public function iOpenTheTabInTheDetailsView($tabName) {
$this->actor->find(self::tabHeaderInDetailsViewNamed($tabName), 10)->click();
}
/**
* @Given I share the link for :fileName
*/
public function iShareTheLinkFor($fileName) {
$this->actor->find(FileListContext::shareActionForFile(self::currentSectionMainView(), $fileName), 10)->click();
$this->actor->find(self::shareLinkCheckbox(), 5)->click();
}
/**
* @Given I write down the shared link
*/
public function iWriteDownTheSharedLink() {
// The shared link field always exists in the DOM (once the "Sharing"
// tab is loaded), but its value is the actual shared link only when it
// is visible.
if (!WaitFor::elementToBeEventuallyShown(
$this->actor,
self::shareLinkField(),
$timeout = 10 * $this->actor->getFindTimeoutMultiplier())) {
PHPUnit_Framework_Assert::fail("The shared link was not shown yet after $timeout seconds");
}
$this->actor->getSharedNotebook()["shared link"] = $this->actor->find(self::shareLinkField())->getValue();
}
/**
* @When I check the tag :tag in the dropdown for tags in the details view
*/
public function iCheckTheTagInTheDropdownForTagsInTheDetailsView($tag) {
$this->iSeeThatTheTagInTheDropdownForTagsInTheDetailsViewIsNotChecked($tag);
$this->actor->find(self::itemInDropdownForTag($tag), 10)->click();
}
/**
* @When I uncheck the tag :tag in the dropdown for tags in the details view
*/
public function iUncheckTheTagInTheDropdownForTagsInTheDetailsView($tag) {
$this->iSeeThatTheTagInTheDropdownForTagsInTheDetailsViewIsChecked($tag);
$this->actor->find(self::itemInDropdownForTag($tag), 10)->click();
}
/**
* @When I set the shared link as editable
*/
public function iSetTheSharedLinkAsEditable() {
$this->actor->find(self::allowUploadAndEditingRadioButton(), 10)->click();
}
/**
* @When I protect the shared link with the password :password
*/
public function iProtectTheSharedLinkWithThePassword($password) {
$this->actor->find(self::passwordProtectCheckbox(), 10)->click();
$this->actor->find(self::passwordProtectField(), 2)->setValue($password . "\r");
}
/**
* @Then I see that the current page is the Files app
*/
public function iSeeThatTheCurrentPageIsTheFilesApp() {
PHPUnit_Framework_Assert::assertStringStartsWith(
$this->actor->locatePath("/apps/files/"),
$this->actor->getSession()->getCurrentUrl());
$this->setFileListAncestorForActor(self::currentSectionMainView(), $this->actor);
}
/**
* @Then I see that the details view is open
*/
public function iSeeThatTheDetailsViewIsOpen() {
// The sidebar always exists in the DOM, so it has to be explicitly
// waited for it to be visible instead of relying on the implicit wait
// made to find the element.
if (!WaitFor::elementToBeEventuallyShown(
$this->actor,
self::detailsView(),
$timeout = 10 * $this->actor->getFindTimeoutMultiplier())) {
PHPUnit_Framework_Assert::fail("The details view is not open yet after $timeout seconds");
}
}
/**
* @Then I see that the details view is closed
*/
public function iSeeThatTheDetailsViewIsClosed() {
if (!WaitFor::elementToBeEventuallyNotShown(
$this->actor,
self::detailsView(),
$timeout = 10 * $this->actor->getFindTimeoutMultiplier())) {
PHPUnit_Framework_Assert::fail("The details view is not closed yet after $timeout seconds");
}
}
/**
* @Then I see that the file name shown in the details view is :fileName
*/
public function iSeeThatTheFileNameShownInTheDetailsViewIs($fileName) {
PHPUnit_Framework_Assert::assertEquals(
$this->actor->find(self::fileNameInDetailsView(), 10)->getText(), $fileName);
}
/**
* @Then I see that the input field for tags in the details view is shown
*/
public function iSeeThatTheInputFieldForTagsInTheDetailsViewIsShown() {
PHPUnit_Framework_Assert::assertTrue(
$this->actor->find(self::inputFieldForTagsInDetailsView(), 10)->isVisible());
}
/**
* @Then I see that the input field for tags in the details view contains the tag :tag
*/
public function iSeeThatTheInputFieldForTagsInTheDetailsViewContainsTheTag($tag) {
PHPUnit_Framework_Assert::assertTrue(
$this->actor->find(self::itemInInputFieldForTagsInDetailsViewForTag($tag), 10)->isVisible());
}
/**
* @Then I see that the input field for tags in the details view does not contain the tag :tag
*/
public function iSeeThatTheInputFieldForTagsInTheDetailsViewDoesNotContainTheTag($tag) {
$this->iSeeThatTheInputFieldForTagsInTheDetailsViewIsShown();
try {
PHPUnit_Framework_Assert::assertFalse(
$this->actor->find(self::itemInInputFieldForTagsInDetailsViewForTag($tag))->isVisible());
} catch (NoSuchElementException $exception) {
}
}
/**
* @Then I see that the tag :tag in the dropdown for tags in the details view is checked
*/
public function iSeeThatTheTagInTheDropdownForTagsInTheDetailsViewIsChecked($tag) {
PHPUnit_Framework_Assert::assertTrue(
$this->actor->find(self::checkmarkInItemInDropdownForTag($tag), 10)->isVisible());
}
/**
* @Then I see that the tag :tag in the dropdown for tags in the details view is not checked
*/
public function iSeeThatTheTagInTheDropdownForTagsInTheDetailsViewIsNotChecked($tag) {
PHPUnit_Framework_Assert::assertTrue(
$this->actor->find(self::itemInDropdownForTag($tag), 10)->isVisible());
PHPUnit_Framework_Assert::assertFalse(
$this->actor->find(self::checkmarkInItemInDropdownForTag($tag))->isVisible());
}
/**
* @When I see that the :tabName tab in the details view is eventually loaded
*/
public function iSeeThatTheTabInTheDetailsViewIsEventuallyLoaded($tabName) {
if (!WaitFor::elementToBeEventuallyNotShown(
$this->actor,
self::loadingIconForTabInDetailsViewNamed($tabName),
$timeout = 10 * $this->actor->getFindTimeoutMultiplier())) {
PHPUnit_Framework_Assert::fail("The $tabName tab in the details view has not been loaded after $timeout seconds");
}
}
/**
* @Then I see that the working icon for password protect is shown
*/
public function iSeeThatTheWorkingIconForPasswordProtectIsShown() {
PHPUnit_Framework_Assert::assertNotNull($this->actor->find(self::passwordProtectWorkingIcon(), 10));
}
/**
* @Then I see that the working icon for password protect is eventually not shown
*/
public function iSeeThatTheWorkingIconForPasswordProtectIsEventuallyNotShown() {
if (!WaitFor::elementToBeEventuallyNotShown(
$this->actor,
self::passwordProtectWorkingIcon(),
$timeout = 10 * $this->actor->getFindTimeoutMultiplier())) {
PHPUnit_Framework_Assert::fail("The working icon for password protect is still shown after $timeout seconds");
}
}
/**
* @Given I share the link for :fileName protected by the password :password
*/
public function iShareTheLinkForProtectedByThePassword($fileName, $password) {
$this->iShareTheLinkFor($fileName);
$this->iProtectTheSharedLinkWithThePassword($password);
$this->iSeeThatTheWorkingIconForPasswordProtectIsShown();
$this->iSeeThatTheWorkingIconForPasswordProtectIsEventuallyNotShown();
}
}