-
Notifications
You must be signed in to change notification settings - Fork 15
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
Refactor of scripts/import-tests #291
Conversation
…; removed sequelize seeders that are no longer relevant
I really like the way you showed changes to the entities! Something we should all talk about is the structure of the parsed tests. I think I saw Seth scheduling a meeting today to talk about it. I sort of pulled the name "sourceSteps" out of my ... head, and what I was imagining is that a step would be part of a parsed test. It's probably not the best name. I think I imagined a step as being equivalent to a command - but it's basically one interaction a tester would do during a test. Anyway that means the way you're using sourceSteps here doesn't match. Your parsed test is my test plan and your source steps is my parsed tests. The solution in my mind is to figure out the structure of generated tests. But that said I think this is mainly a terminology issue and I'm sure this PR won't have to change heavily. But I think it does reveal how important figuring out the test JSON is. |
Thanks! And agreed, think we may just be off center in our interpretation of the naming there but the value stands. And definitely up for continuing to discuss those properties then. Should make it a point to discuss |
@alflennik renamed to |
Sounds good @howard-e - and our meeting is in 15 minutes and I'll report back here if we make any decisions that are relevant! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks awesome, I didn't get totally through it all yet, but here are my questions, almost all of which just come from my anxieties about the open modeling questions! But looks good.
* @param {string} testName - the name of the test | ||
* @param {string} file - the relative path to the test file in the repository (ideally {@link https://github.com/w3c/aria-at.git}) | ||
* @param {number} testPlanId - TestPlan.id to be queried to update the TestPlan.parsedTest.testActions if necessary | ||
* @param {string} commitHash - the hash of the latest version of tests pulled from the repository (ideally {@link https://github.com/w3c/aria-at.git}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should make sure this matches the TestPlan model, so sourceGitCommit
.
Given the fact we need the message too, it could be sourceGitCommitHash
, in which case I'd definitely prefer to update the model from sourceGitCommit
to sourceGitCommitHash
as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was puzzled at first because revision
is being used as the hash here and sourceGitCommit
as the message. But I follow now. I agree.
- Re-purposing
revision
to be the latest tag found for the commit being pulled (may need to look specifically for semver-ed patterns) sourceGitCommit
->sourceGitCommitHash
- Adding
sourceGitCommitMessage
to the TestPlan schema
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! Thanks for adding the message to the TestPlan too, that's a great solution.
As for revision, I think the hope is for it to come from a future version of the ARIA-AT repo, but it currently doesn't exist, haha. Maybe it will be stored with the test source as metadata on the test plan or something. Anyway, maybe the right move is to remove it until it's actually available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, right now we only have the git commit hash and message to track changes. if we include revision
(for future-proofing) I think it should just duplicate the commit hash (since git tags are not really used by the aria-at repo). or, we can remove revision
and add with a migration later.
server/scripts/import-tests/index.js
Outdated
* @param {string} file - the relative path to the test file in the repository (ideally {@link https://github.com/w3c/aria-at.git}) | ||
* @param {number} testPlanId - TestPlan.id to be queried to update the TestPlan.parsedTest.testActions if necessary | ||
* @param {string} commitHash - the hash of the latest version of tests pulled from the repository (ideally {@link https://github.com/w3c/aria-at.git}) | ||
* @param {string} commitMsg - the message of the latest version of tests pulled from the repository (ideally {@link https://github.com/w3c/aria-at.git}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you agree about the sourceGitCommit
I think it would make sense to change this to sourceGitCommitMessage
.
About msg
, one convention I always fight for is to spell out words!!! I think it reduces guesswork and makes variable names easier to remember. I fight for it, but that's definitely an optional suggestion!
); | ||
// short circuit method because parsedTest.testActions.[action] is already present | ||
if (testStepsFound) return testPlan.id; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of testActions
can I suggest commands
? That matches a convention Simon and I sort of settled on a couple months ago.
I think in this case command
is better than testCommand
I want to avoid the trap of putting test in front of every variable name, haha, except in the case where we're too late as in TestPlan.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't commands
in their context refer to the actual keyboard input commands being done?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, in the current code, commands sometimes refers to the keys, but that's definitely something I want to change. And it's not just keys, it will encompass gestures on mobile devices too. In the CG when we touched on this terminology problem, the term "input" came up, which I think fits really well. So I want to gradually rename anything related to input to the name input, and I want to save the term command for the case we're dealing with here, the statements that make up a single test.
input -> the keyboard key or gesture
command -> columns in the test authoring CSV that contains either an instruction or an assertion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm understanding correctly, I think these are just tests
: https://github.com/w3c/aria-at/wiki/Working-Mode#definitions
Using this page as an example:
The hierarchy is: Test Plan ("checkbox") > Test ("Navigate to an unchecked checkbox in reading mode ") > Commands ("X / Shift+X") > Assertion ("Role 'checkbox' is conveyed")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's right Seth - Howard and I talked about it yesterday and that was the conclusion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good! And seems like it might have implications on the name of the field as well? TestPlan.parsedTest
should probably be closer to TestPlan.parsed
since the JSON object is referring to the TestPlan as a whole, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's right.
@@ -0,0 +1,446 @@ | |||
/* eslint no-console: 0 */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is just a copy of the old version I think we can delete this and go back to the Git history if we ever need it, what do you think?
@@ -37,27 +37,24 @@ const tmpDirectory = path.resolve(__dirname, 'tmp'); | |||
const testDirectory = path.resolve(tmpDirectory, 'tests'); | |||
const supportFile = path.resolve(testDirectory, 'support.json'); | |||
|
|||
const ariaat = { | |||
const ariaAtImport = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for changing that name, haha, this is much better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small (perhaps nitpicky) thing: we use "main" as our primary branch, not "master."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, will adjust
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, not seeing the main
branch for aria-at. And master
is still set as default so I suppose that branch rename could be proposed there?
I'll change the verbiage here to reflect a 'default branch' and set a constant for its use here should that change occur
}; | ||
|
||
const exampleUrl = getReferenceUrl(exampleRefLine); | ||
const designPattern = getReferenceUrl(practiceGuidelinesRefLine); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've sort of imagined exampleUrl as replacing the design pattern. Is it possible to eliminate the design pattern here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the exampleUrl
and the APG designPatternUrl
are different properties (example 1) and (example 2), so I'm not entirely sure we want to with that stance. But if there is a reason to no longer have one, that could be discussed.
However, given that the designPattern
lives inside the json object and isn't tied to anything, we could also ignore it for now should it become useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I do know we're going to talk about the references.csv pretty soon as one of the first topics of the larger test authoring format discussion. So yes, I think ... we should remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need to get rid of it unless we don't use it at all. The design pattern is a term that relates to the types of components in the example. See this issue as a reference: w3c/aria-at#402. I think it makes more sense to keep it as it is something that is heavily used in APG. As long as nothing is dependent upon it we can use or not use it as the examples indicate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @jesdaigle that we should not get rid of designPatternUrl
.
There are multiple examples for each APG design pattern. For example, "Checkbox Example (Two State)" is one of two examples under the "Checkbox" design pattern. Each URL has different, but useful contextual information. The CG wants to make it easy to visit either of these links for context for reviewers and testers.
For now, I think we should just track references.csv
.
In the future, I agree with @alflennik that we should advocate for APG-agnostic metadata. This could be accomplished by a rename like: APG Pattern URL → Context URL
or something like that, or it could be accomplished by a freeform json object that has different properties for each source that we're testing (APG, HTML, etc.). We should definitely discuss the pros/cons of these down the road.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for that context @jesdaigle and @s3ththompson I didn't realize the test plans had a hierarchy like that!
…Commit renamed to TestPlan.sourceGitCommitHash and adding TestPlan.sourceGitCommitMessage
@howard-e @alflennik The meeting yesterday was more about the script that generates test files from the CSV files, rather than the actual structure of the test data. As I commented above, I think we want to take a cautious approach to renaming things. Some terms (like "Test Plan", "Test", and "Assertion" are quite established and I don't think we should rename without very good reason). Other terms (like "APG Pattern URL" are definitely too specific and will need to be renamed in the future). For now, I think it's best to only tackle renames that would be hard to do later (or to treat certain test data as opaque JSON). |
* Renamed `TestPlan.parsedTest` -> `TestPlan.parsed` * Renamed `TestPlan.parsed.testActions` -> `TestPlan.parsed.tests`
To continue the migration process, this holds changes for
scripts/import-tests/index.js
which is responsible for ensuring the latest tests can be pulled from thearia-at repository
.Assuming your database has not been initialized, run:
Changes:
test_version
&apg_example
INSERT instructions and attributes have now been converted to top level TestPlan records. Other additional attributes of those original tables have also been moved intoTestPlan.parsed
.test
has mostly been converted intoTestPlan.parsedTest.sourceSteps
TestPlan.parsed.tests
to detail the relevant assertion tests to be done.TestPlan.parsed.maximumInputCount
test_version
+apg_example
+test
->TestPlan
test_version [OLD]
apg_example [OLD]
test [OLD]
TestPlan [NEW]
TestPlan.parsed Example