2017-04-22 19:20:32 +03:00
|
|
|
Feature: app-files
|
|
|
|
|
2017-04-22 19:20:32 +03:00
|
|
|
Scenario: viewing a favorite file in its folder closes the details view
|
|
|
|
Given I am logged in
|
|
|
|
And I mark "welcome.txt" as favorite
|
|
|
|
And I see that "welcome.txt" is marked as favorite
|
|
|
|
And I open the "Favorites" section
|
|
|
|
And I open the details view for "welcome.txt"
|
|
|
|
And I see that the details view for "Favorites" section is open
|
|
|
|
When I view "welcome.txt" in folder
|
|
|
|
Then I see that the current section is "All files"
|
|
|
|
And I see that the details view is closed
|
|
|
|
|
|
|
|
Scenario: viewing a favorite file in its folder does not prevent opening the details view in "All files" section
|
|
|
|
Given I am logged in
|
|
|
|
And I mark "welcome.txt" as favorite
|
|
|
|
And I see that "welcome.txt" is marked as favorite
|
|
|
|
And I open the "Favorites" section
|
|
|
|
And I open the details view for "welcome.txt"
|
|
|
|
And I see that the details view for "Favorites" section is open
|
|
|
|
And I view "welcome.txt" in folder
|
|
|
|
And I see that the current section is "All files"
|
|
|
|
When I open the details view for "welcome.txt"
|
|
|
|
Then I see that the details view for "All files" section is open
|
|
|
|
|
2018-01-11 06:30:52 +03:00
|
|
|
Scenario: rename a file with the details view open
|
|
|
|
Given I am logged in
|
|
|
|
And I open the details view for "welcome.txt"
|
|
|
|
When I rename "welcome.txt" to "farewell.txt"
|
|
|
|
Then I see that the file list contains a file named "farewell.txt"
|
|
|
|
And I see that the file name shown in the details view is "farewell.txt"
|
|
|
|
|
2017-12-19 08:55:47 +03:00
|
|
|
Scenario: open the menu in a public shared link
|
|
|
|
Given I act as John
|
|
|
|
And I am logged in
|
|
|
|
And I share the link for "welcome.txt"
|
|
|
|
And I write down the shared link
|
|
|
|
When I act as Jane
|
|
|
|
And I visit the shared link I wrote down
|
|
|
|
And I see that the current page is the shared link I wrote down
|
|
|
|
And I open the Share menu
|
|
|
|
Then I see that the Share menu is shown
|
|
|
|
|
2017-04-22 19:20:32 +03:00
|
|
|
Scenario: set a password to a shared link
|
|
|
|
Given I am logged in
|
|
|
|
And I share the link for "welcome.txt"
|
|
|
|
When I protect the shared link with the password "abcdef"
|
|
|
|
Then I see that the working icon for password protect is shown
|
|
|
|
And I see that the working icon for password protect is eventually not shown
|
|
|
|
|
|
|
|
Scenario: access a shared link protected by password with a valid password
|
|
|
|
Given I act as John
|
|
|
|
And I am logged in
|
|
|
|
And I share the link for "welcome.txt" protected by the password "abcdef"
|
|
|
|
And I write down the shared link
|
|
|
|
When I act as Jane
|
|
|
|
And I visit the shared link I wrote down
|
|
|
|
And I see that the current page is the Authenticate page for the shared link I wrote down
|
|
|
|
And I authenticate with password "abcdef"
|
|
|
|
Then I see that the current page is the shared link I wrote down
|
|
|
|
And I see that the shared file preview shows the text "Welcome to your Nextcloud account!"
|
|
|
|
|
|
|
|
Scenario: access a shared link protected by password with an invalid password
|
|
|
|
Given I act as John
|
|
|
|
And I am logged in
|
|
|
|
And I share the link for "welcome.txt" protected by the password "abcdef"
|
|
|
|
And I write down the shared link
|
|
|
|
When I act as Jane
|
|
|
|
And I visit the shared link I wrote down
|
|
|
|
And I authenticate with password "fedcba"
|
|
|
|
Then I see that the current page is the Authenticate page for the shared link I wrote down
|
|
|
|
And I see that a wrong password for the shared file message is shown
|
2017-06-09 04:02:33 +03:00
|
|
|
|
|
|
|
Scenario: show the input field for tags in the details view
|
|
|
|
Given I am logged in
|
|
|
|
And I open the details view for "welcome.txt"
|
|
|
|
And I see that the details view for "All files" section is open
|
|
|
|
When I open the input field for tags in the details view
|
|
|
|
Then I see that the input field for tags in the details view is shown
|
|
|
|
|
|
|
|
Scenario: show the input field for tags in the details view after the sharing tab has loaded
|
|
|
|
Given I am logged in
|
|
|
|
And I open the details view for "welcome.txt"
|
|
|
|
And I see that the details view for "All files" section is open
|
|
|
|
And I open the "Sharing" tab in the details view
|
|
|
|
And I see that the "Sharing" tab in the details view is eventually loaded
|
|
|
|
When I open the input field for tags in the details view
|
|
|
|
Then I see that the input field for tags in the details view is shown
|
2017-07-05 15:54:26 +03:00
|
|
|
|
2017-07-08 16:46:16 +03:00
|
|
|
Scenario: create tags using the Administration settings
|
|
|
|
Given I am logged in as the admin
|
|
|
|
And I visit the settings page
|
|
|
|
And I open the "Workflow" section
|
|
|
|
# The "create" button does nothing before JavaScript was initialized, and
|
|
|
|
# the only way to detect that is waiting for the button to select tags to be
|
|
|
|
# shown.
|
|
|
|
And I see that the button to select tags is shown
|
|
|
|
When I create the tag "tag1" in the settings
|
|
|
|
Then I see that the dropdown for tags in the settings eventually contains the tag "tag1"
|
|
|
|
|
|
|
|
Scenario: add tags using the dropdown in the details view
|
|
|
|
Given I am logged in as the admin
|
|
|
|
And I visit the settings page
|
|
|
|
And I open the "Workflow" section
|
|
|
|
# The "create" button does nothing before JavaScript was initialized, and
|
|
|
|
# the only way to detect that is waiting for the button to select tags to be
|
|
|
|
# shown.
|
|
|
|
And I see that the button to select tags is shown
|
|
|
|
And I create the tag "tag1" in the settings
|
|
|
|
And I create the tag "tag2" in the settings
|
|
|
|
And I create the tag "tag3" in the settings
|
|
|
|
And I create the tag "tag4" in the settings
|
|
|
|
And I see that the dropdown for tags in the settings eventually contains the tag "tag1"
|
|
|
|
And I see that the dropdown for tags in the settings eventually contains the tag "tag2"
|
|
|
|
And I see that the dropdown for tags in the settings eventually contains the tag "tag3"
|
|
|
|
And I see that the dropdown for tags in the settings eventually contains the tag "tag4"
|
|
|
|
And I log out
|
|
|
|
And I am logged in
|
|
|
|
And I open the details view for "welcome.txt"
|
|
|
|
And I open the input field for tags in the details view
|
|
|
|
# When the input field is opened the dropdown is also opened automatically.
|
|
|
|
When I check the tag "tag2" in the dropdown for tags in the details view
|
|
|
|
And I check the tag "tag4" in the dropdown for tags in the details view
|
|
|
|
Then I see that the tag "tag2" in the dropdown for tags in the details view is checked
|
|
|
|
And I see that the tag "tag4" in the dropdown for tags in the details view is checked
|
|
|
|
And I see that the input field for tags in the details view contains the tag "tag2"
|
|
|
|
And I see that the input field for tags in the details view contains the tag "tag4"
|
|
|
|
|
|
|
|
Scenario: remove tags using the dropdown in the details view
|
|
|
|
Given I am logged in as the admin
|
|
|
|
And I visit the settings page
|
|
|
|
And I open the "Workflow" section
|
|
|
|
# The "create" button does nothing before JavaScript was initialized, and
|
|
|
|
# the only way to detect that is waiting for the button to select tags to be
|
|
|
|
# shown.
|
|
|
|
And I see that the button to select tags is shown
|
|
|
|
And I create the tag "tag1" in the settings
|
|
|
|
And I create the tag "tag2" in the settings
|
|
|
|
And I create the tag "tag3" in the settings
|
|
|
|
And I create the tag "tag4" in the settings
|
|
|
|
And I see that the dropdown for tags in the settings eventually contains the tag "tag1"
|
|
|
|
And I see that the dropdown for tags in the settings eventually contains the tag "tag2"
|
|
|
|
And I see that the dropdown for tags in the settings eventually contains the tag "tag3"
|
|
|
|
And I see that the dropdown for tags in the settings eventually contains the tag "tag4"
|
|
|
|
And I log out
|
|
|
|
And I am logged in
|
|
|
|
And I open the details view for "welcome.txt"
|
|
|
|
And I open the input field for tags in the details view
|
|
|
|
# When the input field is opened the dropdown is also opened automatically.
|
|
|
|
And I check the tag "tag2" in the dropdown for tags in the details view
|
|
|
|
And I check the tag "tag4" in the dropdown for tags in the details view
|
|
|
|
And I check the tag "tag3" in the dropdown for tags in the details view
|
|
|
|
When I uncheck the tag "tag2" in the dropdown for tags in the details view
|
|
|
|
And I uncheck the tag "tag4" in the dropdown for tags in the details view
|
|
|
|
Then I see that the tag "tag2" in the dropdown for tags in the details view is not checked
|
|
|
|
And I see that the tag "tag4" in the dropdown for tags in the details view is not checked
|
|
|
|
And I see that the tag "tag3" in the dropdown for tags in the details view is checked
|
|
|
|
And I see that the input field for tags in the details view does not contain the tag "tag2"
|
|
|
|
And I see that the input field for tags in the details view does not contain the tag "tag4"
|
|
|
|
And I see that the input field for tags in the details view contains the tag "tag3"
|
|
|
|
|
2017-07-05 15:54:26 +03:00
|
|
|
Scenario: marking a file as favorite causes the file list to be sorted again
|
|
|
|
Given I am logged in
|
|
|
|
And I create a new folder named "A name alphabetically lower than welcome.txt"
|
|
|
|
And I see that "A name alphabetically lower than welcome.txt" precedes "welcome.txt" in the file list
|
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
|
|
|
# To mark the file as favorite the file actions menu has to be shown but, as
|
|
|
|
# the details view is opened automatically when the folder is created,
|
|
|
|
# clicking on the menu trigger could fail if it is covered by the details
|
|
|
|
# view due to its opening animation. Instead of ensuring that the animations
|
|
|
|
# of the contents and the details view have both finished it is easier to
|
|
|
|
# close the details view and wait until it is closed before continuing.
|
|
|
|
And I close the details view
|
|
|
|
And I see that the details view is closed
|
2017-07-05 15:54:26 +03:00
|
|
|
When I mark "welcome.txt" as favorite
|
|
|
|
Then I see that "welcome.txt" is marked as favorite
|
|
|
|
And I see that "welcome.txt" precedes "A name alphabetically lower than welcome.txt" in the file list
|
|
|
|
|
|
|
|
Scenario: unmarking a file as favorite causes the file list to be sorted again
|
|
|
|
Given I am logged in
|
|
|
|
And I create a new folder named "A name alphabetically lower than welcome.txt"
|
|
|
|
And I see that "A name alphabetically lower than welcome.txt" precedes "welcome.txt" in the file list
|
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
|
|
|
# To mark the file as favorite the file actions menu has to be shown but, as
|
|
|
|
# the details view is opened automatically when the folder is created,
|
|
|
|
# clicking on the menu trigger could fail if it is covered by the details
|
|
|
|
# view due to its opening animation. Instead of ensuring that the animations
|
|
|
|
# of the contents and the details view have both finished it is easier to
|
|
|
|
# close the details view and wait until it is closed before continuing.
|
|
|
|
And I close the details view
|
|
|
|
And I see that the details view is closed
|
2017-07-05 15:54:26 +03:00
|
|
|
And I mark "welcome.txt" as favorite
|
|
|
|
And I see that "welcome.txt" is marked as favorite
|
|
|
|
And I see that "welcome.txt" precedes "A name alphabetically lower than welcome.txt" in the file list
|
|
|
|
When I unmark "welcome.txt" as favorite
|
|
|
|
Then I see that "welcome.txt" is not marked as favorite
|
|
|
|
And I see that "A name alphabetically lower than welcome.txt" precedes "welcome.txt" in the file list
|