Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Turn editor tests back on after getting them to pass (Outreachy related) #8858

Closed
jywarren opened this issue Dec 16, 2020 · 13 comments
Closed
Assignees
Labels
high-priority testing issues are usually for adding unit tests, integration tests or any other tests for a feature

Comments

@jywarren
Copy link
Member

jywarren commented Dec 16, 2020

To finish moving off Travis and into GitHub Actions in #8795, I turned off all 4 tests in /test/system/editor_test.rb

Here's the commit:

8bbbaf8

We just need to turn them back on and figure out why they aren't passing; here are the errors:

[Screenshot]: tmp/screenshots/failures_test_check_markdown_editor_features_are_functional.png
ERROR["test_check_markdown_editor_features_are_functional", #<Minitest::Reporters::Suite:0x00007f34518414d0 @name="EditorTest">, 90.52515762799999]
 test_check_markdown_editor_features_are_functional#EditorTest (90.53s)
Minitest::UnexpectedError:         Capybara::ElementNotFound: Unable to find css "a[data-original-title='Edit this wiki page.']"
            test/system/editor_test.rb:66:in `block in <class:EditorTest>'

[Screenshot]: tmp/screenshots/failures_test_check_rich_editor_features_are_functional.png
ERROR["test_check_rich_editor_features_are_functional", #<Minitest::Reporters::Suite:0x00007f345b370b40 @name="EditorTest">, 153.1470894050001]
 test_check_rich_editor_features_are_functional#EditorTest (153.15s)
Minitest::UnexpectedError:         Capybara::ElementNotFound: Unable to find css "a[data-original-title='Try the beta inline Rich Wiki editor.'"
            test/system/editor_test.rb:42:in `block in <class:EditorTest>'

[Screenshot]: tmp/screenshots/failures_test_check_that_markdown_wiki_editor_functions_correctly.png
ERROR["test_check_that_markdown_wiki_editor_functions_correctly", #<Minitest::Reporters::Suite:0x00007f345ad811a8 @name="EditorTest">, 215.64896502800002]
 test_check_that_markdown_wiki_editor_functions_correctly#EditorTest (215.65s)
Minitest::UnexpectedError:         Capybara::ElementNotFound: Unable to find css "a[data-original-title='Edit this wiki page.'"
            test/system/editor_test.rb:32:in `block in <class:EditorTest>'

=[Screenshot]: tmp/screenshots/failures_test_check_that_rich_wiki_editor_functions_correctly.png
ERROR["test_check_that_rich_wiki_editor_functions_correctly", #<Minitest::Reporters::Suite:0x00007f345b28f118 @name="EditorTest">, 278.21773055100016]
 test_check_that_rich_wiki_editor_functions_correctly#EditorTest (278.22s)
Minitest::UnexpectedError:         Capybara::ElementNotFound: Unable to find css "a[data-original-title='Try the beta inline Rich Wiki editor.'"
            test/system/editor_test.rb:18:in `block in <class:EditorTest>'
@jywarren jywarren added high-priority testing issues are usually for adding unit tests, integration tests or any other tests for a feature labels Dec 16, 2020
@jywarren
Copy link
Member Author

Hi @Uzay-G - i hope you're well - i've turned off these tests as i couldn't get them to work in Github Actions... do you have any ideas or suggestions as to why we aren't seeing them working? I remember you added them originally. I've moved the file to:

# test "check that rich wiki editor functions correctly" do
# visit "/wiki/wiki-page-path"
# find("a[data-original-title='Try the beta inline Rich Wiki editor.'").click()
# first("div.inline-section").hover()
# # click edit btn
# using_wait_time(2) { first("a.inline-edit-btn").click() }
# find("div.wk-wysiwyg").set("wiki text")
# click_on "Save"
# page.assert_selector("p", text: "wiki text")
# end
# test "check that markdown wiki editor functions correctly" do
# visit "/wiki/wiki-page-path"
# find("a[data-original-title='Edit this wiki page.'").click()
# find("#text-input").set("wiki text")
# find("a#publish").click()
# page.assert_selector("p", text: "wiki text")
# end
# test "check rich editor features are functional" do
# visit "/wiki/wiki-page-path"
# find("a[data-original-title='Try the beta inline Rich Wiki editor.'").click()
# first("div.inline-section").hover()
# using_wait_time(2) { first("a.inline-edit-btn").click() }
# # test the following features
# ["bold", "italic", "code", "heading"].each do |element|
# # clicking on the button generates the element with dummy text
# find("button.woofmark-command-#{element}").click()
# # these keys are called to deselect the previous elements
# find("div.wk-wysiwyg").native.send_key(:arrow_left, :enter)
# end
# click_on "Save"
# # assert that the features have worked and that the correct wiki elements are displayed
# page.assert_selector("strong", text: "strong text")
# page.assert_selector("h1", text: "Heading Text")
# page.assert_selector("em", text: "emphasized text")
# page.assert_selector("code", text: "code goes here")
# end
# test "check markdown editor features are functional" do
# visit "/wiki/wiki-page-path"
# find("a[data-original-title='Edit this wiki page.']").click()
# # test the following features
# ["**strong text**", "_emphasized text_", "`code goes here`", "# Heading Text"].each do |element|
# find("#text-input").native.send_keys(element)
# find("#text-input").native.send_keys(:enter)
# end
# find("a#publish").click()
# # assert that the features have worked and that the correct wiki elements are displayed
# page.assert_selector("strong", text: "strong text")
# page.assert_selector("h1", text: "Heading Text")
# page.assert_selector("em", text: "emphasized text")
# page.assert_selector("code", text: "code goes here")
# end

Thank you!

@noi5e
Copy link
Contributor

noi5e commented Jan 5, 2021

It looks like the views at wiki#show and wiki#edit have changed a lot since this test was written. Here's the screenshot from the test:

failures_test_check_markdown_editor_features_are_functional

The pencil's selector is now #edit-btn, not a[data-original-title='Edit this wiki page.'].

@cesswairimu cesswairimu self-assigned this Jan 14, 2021
@cesswairimu
Copy link
Collaborator

cesswairimu commented Jan 19, 2021

As I mentioned, I was checking into these and found that this text

# find("a[data-original-title='Try the beta inline Rich Wiki editor.'").click()

is no longer rendered on that page...causing a couple of these to fail...also a lot of names, divs and ids have changed as @noi5e mentioned above
Also a couple of these scenarios are tested here https://github.com/publiclab/plots2/blame/main/test/system/post_test.rb so we could remove the tests already covered inline with what Will was talking about

@noi5e
Copy link
Contributor

noi5e commented Jan 19, 2021

This may or may not be related, but I was asking in the meeting today... Is it even possible to access the legacy editor through /wiki/edit or /wiki/new (or even anywhere else on the site?)

All of these appear to be using the rich-text editor (I think?). I can't find a link or other way to access the legacy editor in these pages... @jywarren Do you see the same things when you visit these pages? We were talking in the meeting about maybe admins or senior user accounts might still have access to the legacy editor.

This does affect Comment Editor work at #8775, because scripts like editor.js and dragdrop.js are required in some pages that use the legacy editor... But if we're going to clean up controllers and views, maybe I don't have to worry about these contexts.

I also acknowledge that I may not actually know what the phrase "legacy editor" refers to... Like, maybe I've never even seen one live!

/features/new seems to still be live here, and it's using a pretty bare-bones editor (which still has rich-text buttons and things):
Screen Shot 2021-01-19 at 11 40 14 AM

Does this count as a legacy editor?

@jywarren
Copy link
Member Author

@cesswairimu i see so maybe what happened is that the tests being in a nonstandard location meant that they weren't running at all before and slowly drifted out of being in sync with the actual pages. Then once we moved them back they activated but were no longer appropriate for the latest page markup?

@jywarren
Copy link
Member Author

Agreed though let's remove what's redundant and trim the rest, if possible!

@cesswairimu
Copy link
Collaborator

Wonderful! that totally explains it Jeff

@ebarry
Copy link
Member

ebarry commented Jan 19, 2021

the one bit i'm sure of is that /features/new is fine as is. it's just a special editor where site admins can write html and stuff for special places.

@jywarren
Copy link
Member Author

Thanks for investigating this one Cess! Great job!

@jywarren
Copy link
Member Author

@noi5e did Cess's comments in the chatroom clarify things? I think sharing screenshots of both states will help disambiguate, if not.

What do you think of leaving these tests off? Or, of how they might be redundant with tests you're writing?

@jywarren jywarren changed the title Turn editor tests back on after getting them to pass Turn editor tests back on after getting them to pass (Outreachy related) Jan 20, 2021
@noi5e
Copy link
Contributor

noi5e commented Jan 20, 2021

@jywarren I have greater clarity about legacy vs rich text editor now!

I don't think system tests for the rich-text editor will affect my work much. It seems like the rich-text editor is using separate JavaScripts? I'm more trying to catch instances of the legacy editor that still require dragdrop.js.

Regarding this issue: yes, we can leave the tests off, if it makes sense. I agree, it seems like these tests just became inaccurate after being unused, and now just need to be rewritten with different selectors (doesn't seem like a lot of work TBH)

@jywarren
Copy link
Member Author

OK. Let's close this and if there are opportunities to rebuild those tests that's fine as well. Thanks, all!

@cesswairimu
Copy link
Collaborator

Thanks Jeff, should I create an issue to add a link to the beta editor or we are good for now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
high-priority testing issues are usually for adding unit tests, integration tests or any other tests for a feature
Projects
None yet
Development

No branches or pull requests

4 participants