-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add a means to compare two results within a single test #12
Comments
… (patchset #12 id:210001 of https://codereview.chromium.org/2455093002/ ) Reason for revert: This patch breaks DevTools toolbars (Console gear icon, checkbox labels are centered), it also seems to break the Welcome to Chrome page layout. Original issue's description: > [css-align] Don't resolve 'auto' values for computed style. > > The CSS Box Alignment specification has been changed recently so that > now all the propeties have the specificed value as computed value. The > rationale of this change are at the associated W3C github issue [1]. > > This change implies that we don't need to execute the StyleAdjuter > logic we implemented specifically for supporting 'auto' values > resolution for computed style. We can live now with resolution at > layout time only. > > [1] w3c/csswg-drafts#440 > > BUG=725489 > > Review-Url: https://codereview.chromium.org/2455093002 > Cr-Commit-Position: refs/heads/master@{#475400} > Committed: https://chromium.googlesource.com/chromium/src/+/5389373c6dec30d783eb46b4c8190720f411a8a7 TBR=cbiesinger@chromium.org,cbiesinger@google.com,meade@chromium.org,rego@igalia.com,svillar@igalia.com,jfernandez@igalia.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=725489 Review-Url: https://codereview.chromium.org/2913093002 Cr-Commit-Position: refs/heads/master@{#475689}
umm... We would need some sort of wiki syntax for this. Otherwise I don't see why not. |
Do you have any ideas/proposals? It would be nice to run the tests in an automated fashion, and in the near future, if at all possible. |
Not yet. Question: in this example, if the result of the first step is fail... doesn't the whole test fail? I mean - there are no examples in WPT of a fail result meaning that the overall test case passes as far as I know. |
I'm afraid I don't follow. Hypothetical example of what I'd like to address: Given two elements, test1 and test2, In other words, step 1 isn't a pass/fail test; it's like an event (sorta). But instead of, say, setting focus, we're obtaining a value for later comparison. |
Oh! Given our syntactic limitations, it would need to be a new "verb" like "is" or "contains". property|role|rememberIn|{variableName} then in some other step property|role|whatever verb|{variableName} I know role is a horrible example, but you get the idea. The braces are something we are not currently using so it would be a reasonable delimiter I think. Thoughts? |
I like the idea and think it would work for getting a simple value; however I don't think it will work for everything we might need it to. One of the things we test is for states in a state set, e.g.: property|states|contains|STATE_FOCUSABLE In that case, we'd want to store the boolean result for the element with id test1, run the same test for the element with id test2, and compare the two boolean results. Brainstorming: Could the rememberIn be the test step type and then add an additional comparison test step type? element test1 |
Hmm... "contains" is an assertion. So it would pass or fail. There's no way around that if we want to retain the current syntax. So no, I don't think that would achieve what you are looking for. |
Fair enough. But what I write above, while broken for the reason you state, is the sort of thing we need to be able to do. Any brilliant (or otherwise) solutions? :) |
Do you anticipate the evaluation being done in the ATTA or in the client (ATTAcomm.js) ? |
For the most part, I would think the client could handle it. But if we ever had a case where the two results being compared or examined required platform-specific knowledge, then the ATTA would need to do it. So having the ATTAs do the evalution work seems safer to me. What do you think? |
I actually don't think the client can handle it.... the client doesn't have any of the information that the ATTAs have. The ATTAs do everything. All we could have the client do is retain information on the reply from the ATTA to a query. Which might be fine... Extend the syntax of one of the columns to mean "this statement is NOT a test; remember its result in a variable named foo". Then the ATTA could do the initial processing and the client could do any test based upon the result. element test1 or something like that.... could do it on the verb as well: element test1 Do either of those resonate? |
One example use case is described in the ARIA 1.1 testable statements wiki, namely:
In other words, the first test step would get -- and save for later comparison -- whether or not a child of a button was exposed. The second test step would get whether or not a child of a tab was exposed. The expected result of the second test step is that the value is the same as what was obtained for the result of the first test step.
The text was updated successfully, but these errors were encountered: