Skip to content

Studio: Adds HTML5 data-* Attributes as Test Logic Hooks (WIP - DO NOT MERGE) #1780

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.

Sign up for GitHub

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

Jump to bottom
Closed
talbs wants to merge 1 commit into from
Closed

Studio: Adds HTML5 data-* Attributes as Test Logic Hooks (WIP - DO NOT MERGE) #1780

talbs wants to merge 1 commit into from

Conversation

@talbs
Copy link
Contributor

@talbs talbs commented Nov 26, 2013

This experimental work aims to help the test engineering group with more solid (and less often to be edited) HTML attributes to use as points of logic when writing interface/state tests.

Currently the attributes added include:

  • data-view -- this is used on each whole view's <body> element
  • data-menu -- this is used to denote any non-native but common UI menu type we may be using (values used: "dropdown")
  • data-rel -- this is used on any link to clarify its scope in relation to the current browser window/domain (values used now: "external" -- an outside site or third party)

Other suggestions are welcome and I will reach out to @jzoldak and @wedaly to see what other UI hooks (elements/states) might be useful to make.

@talbs
Copy link
Contributor Author

talbs commented Nov 26, 2013

@jzoldak and @wedaly, this is some quick work I thought about on the way home and after comparing notes with another designer/FED colleague - my hopes is that it can help you and the UI-focused tests that are written have more solid HTML hooks that will not change even if we cosmetically need to change classes or even HTML elements themselves.

Let me know if you have a few to chat about the idea, if it helps you at all, and what other UI elements or states (errors, confirmations, etc.) would be good to also formalize into data-* attribute patterns.

@talbs
Copy link
Contributor Author

talbs commented Nov 26, 2013

@frrrances and @marcotuts, let me know if you guys agree with this approach as well.

@marcotuts
Copy link
Contributor

marcotuts commented Nov 26, 2013

This looks great!
My one thought here is that it may be worth the time before landing this to document the full list of data labels and where we expect to use them. I know this is marked WIP, but this additional bit of work would be helpful I think, even it it takes the form of a documentation file in the repo denoting all the uses of the data-X-X format. There may be other ways to do this, but the explanation for these attributes would also be helpful for the openedX community whenever this lands.

There may be additional future work around seeing which of our views have these attributes and which don't, but that doesn't seem to be a requirement necessarily in my mind.

Thoughts?
Thanks for putting this together.

@jzoldak
Copy link
Contributor

jzoldak commented Nov 26, 2013

@talbs This is awesome.

Here's our end to end testing repo where we've started to the new bok-choy framework.

We're working on getting the page object definitions into Will's branch in the edx-platform repo, and leveraging them with both the old (lettuce) and the new (bok-choy) browser-level tests. Look in the selenium_pages folder under cms and lms.

In general, what is helpful is:

  • Something to use to determine that you are on the right page
  • For each of the elements on the page that we need to interact with, a definitive way for locating each of them. This will be used doing things like grabbing their text, navigating by clicking on links, etc.
  • A way of knowing that the page has finished rendering. So far we're using lists of RequireJS dependencies and JavaScript globals to wait for.

@frrrances
Copy link
Contributor

frrrances commented Nov 26, 2013

Nice work, Brian. I think this is a great idea and I second @marcotuts's suggestions. Let me know if I can help at all.

@wedaly
Copy link
Contributor

wedaly commented Nov 26, 2013

Nice! I second @marcotuts 's suggestion to document this: it would be nice to have a consistent guide for the LMS team to use.

In addition to the items @jzoldak listed, the pain points for me are:

  • Checking that state changes are completed (animations, loading content, buttons enabled, etc).
  • Referencing a particular element in a list (e.g. "Click the course link with course ID edx/100/test_course"). It would be nice to have the DOM include information at the course level (course IDs, section titles, etc.)

@singingwolfboy
Copy link
Contributor

singingwolfboy commented Dec 31, 2013

What's the status of this pull request? Is it actively being worked on, or can it be closed?

@talbs
Copy link
Contributor Author

talbs commented Jan 3, 2014

@singingwolfboy, thanks for the follow-up. I'm still working on this branch (1 part documentation and philosophy review, which I think you'll be involved in shortly and 1 part implementing these new HTML attributes once that review is complete).

I'll close it for the time being and re-open once I have implementation to be reviewed and merged.

@talbs talbs closed this Jan 3, 2014
jenkins-ks pushed a commit to nttks/edx-platform that referenced this pull request Mar 24, 2017
@hachiyanagi-ks
Fix mail message for create_certs openedx#1772 (openedx#1780)
aa52dfe 
* Fix mail message for create_certs openedx#1772, openedx#1773

* Fix review
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

7 participants

@talbs @marcotuts @jzoldak @frrrances @wedaly @singingwolfboy