-
Notifications
You must be signed in to change notification settings - Fork 4
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
Automation for Creating Polygons from Existing Points #2360
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2360 +/- ##
===========================================
- Coverage 85.85% 54.64% -31.21%
===========================================
Files 738 729 -9
Lines 37855 37704 -151
Branches 9635 9612 -23
===========================================
- Hits 32502 20605 -11897
- Misses 5046 16072 +11026
- Partials 307 1027 +720
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
collaborative-learning Run #13685
Run Properties:
|
Project |
collaborative-learning
|
Branch Review |
187809206-automation-polygon-points
|
Run status |
Passed #13685
|
Run duration | 01m 44s |
Commit |
7316e7870a: Merge branch '187809206-automation-polygon-points' of https://github.com/concord...
|
Committer | Boris Goldowsky |
View all properties for this run ↗︎ |
Test results | |
---|---|
Failures |
0
|
Flaky |
0
|
Pending |
0
|
Skipped |
0
|
Passing |
1
|
View all changes introduced in this branch ↗︎ |
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.
Do these tests fit better in geometry.spec.ts or one of the table tile tests?
The test you have written most properly belongs in geometry_table_integration_test_spec.js
, since it involves both geometry and table tiles.
Do we want to add anything, such as resizing a polygon with the keyboard keys and confirming the resize functionality is working?
A test of keyboard functions wouldn't hurt - there isn't really a resize, but the arrow keys should work to move a point (or several points, whatever is selected). Also the delete and backspace keys should work to remove objects.
As far as testing the creation of polygons from existing points - I would take a look at geometry_tool_spec.js
lines 280-292 which has the most basic version of this, creating a triangle from three points. What I think would be most useful is to extend this to capture some of the related functionality:
- Create a second polygon that shares a point with the first polygon.
- After creating a polygon, click one of its vertexes to go back into editing it, add a point or two, then close it again. Try adding both a new point and an existing point.
Thanks, @bgoldowsky! I'll take a crack at it tomorrow. Those fixes make sense to me! |
d10fc0f
to
fde91f7
Compare
fde91f7
to
d83ab5e
Compare
…points, Add a point to the existing polygon
d83ab5e
to
f90f5a1
Compare
@bgoldowsky - thank you for your feedback! I made the changes you requested, and I believe we now have coverage for what we need. However, please let me know if any additional tests should be implemented. One thing I noticed: I added a test for "Delete point using keyboard command," but I saw that the subsequent test (labeling points) now looks for labels "BCA" instead of "ABC." Is this a bug? It doesn't seem to cause issues in the e2e specs, but it might impact undo/redo in the DOM, for example. Let me know what you think—I wasn't entirely sure what’s happening there. Also, at the end of the circle tests, I noticed two trailing points that don’t get deleted. Is that expected behavior? Just wanted to double-check. For the delete points test, I used undo to revert the deleted point and start fresh for the next test. I'm wondering if that's best practice since Cypress has a spec below mine that explicitly tests undo/redo. |
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.
This is great progress! - there are a few issues that I have noted that still need attention though.
To answer your questions:
- The change from "ABC" to "BCA" is a little mysterious. I think it may have to do with deleting one of the points and then re-creating it, the order gets altered.
- The circle test deletes a point at the end but doesn't delete all of the points - I think it's fine. It is just making sure that the circle goes away if either of the points that define it is removed.
- I think using 'undo' to reset things after a test is ok, but it can make it a little harder to read and reason about the test since exactly how much gets reverted by clicking undo once is not always obvious.
// Verify that the point has moved to approximately (5.1, 4.9) | ||
geometryToolTile.getGraphPoint().then(($points) => { | ||
const movedPoint = $points.filter((index, el) => { | ||
const cx = parseFloat(el.getAttribute('cx')); | ||
const cy = parseFloat(el.getAttribute('cy')); | ||
return Math.abs(cx - 5.1) < 0.1 && Math.abs(cy - 4.9) < 0.1; | ||
}); | ||
expect(movedPoint).to.have.length(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.
I think you meant to write expect(movedPoint).to.have.length(1)
, rather than 0 here, to test that a point matching that description does exist. Unfortunately I don't think this can work since the cx
and cy
attributes in the SVG are in screen pixel units, not the units that are shown on the graph axis.
What I would suggest is to turn on the coordinates label for the point before moving it -- so if it's selected, something like
clueCanvas.clickToolbarButton('geometry', 'label');
geometryToolTile.chooseLabelOption('length');
geometryToolTile.getGraphPointLabel().contains('5.00, 5.00').should('exist');
Then move it and test that the label should show the new coordinates.
And/or, check that the angle label, which was 90 degrees in line 213, shows some other value.
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.
Just to add to Boris's idea here: rather than just checking that the cx & cy points, or the angle, have changed, you could check that the values are greater than (for the cx value) or less than (for the cy value) the previous values. (I'm not sure which angle is referred to here, or whether that angle would increase or decrease, but the same idea applies.)
// Verify that the point has moved to approximately (15.1, 4.9) | ||
geometryToolTile.getGraphPoint().then(($points) => { | ||
const movedPoint = $points.filter((index, el) => { | ||
const cx = parseFloat(el.getAttribute('cx')); | ||
const cy = parseFloat(el.getAttribute('cy')); | ||
return Math.abs(cx - 15.1) < 0.1 && Math.abs(cy - 4.9) < 0.1; | ||
}); | ||
expect(movedPoint).to.have.length(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.
Ideally we'd like some way to check that both polygons have been modified by moving the single shared point. Perhaps a segment in each polygon could be labeled with its length, and you could check that both lengths were altered?
cypress/e2e/functional/tile_tests/geometry_table_integraton_test_spec.js
Outdated
Show resolved
Hide resolved
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 have little to add to Boris's comments - just that one small comment I made. Aside from those suggestions, it looks good to me: I Approve, with those changes.
// Verify that the point has moved to approximately (5.1, 4.9) | ||
geometryToolTile.getGraphPoint().then(($points) => { | ||
const movedPoint = $points.filter((index, el) => { | ||
const cx = parseFloat(el.getAttribute('cx')); | ||
const cy = parseFloat(el.getAttribute('cy')); | ||
return Math.abs(cx - 5.1) < 0.1 && Math.abs(cy - 4.9) < 0.1; | ||
}); | ||
expect(movedPoint).to.have.length(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.
Just to add to Boris's idea here: rather than just checking that the cx & cy points, or the angle, have changed, you could check that the values are greater than (for the cx value) or less than (for the cy value) the previous values. (I'm not sure which angle is referred to here, or whether that angle would increase or decrease, but the same idea applies.)
In this PR, I made the following changes:
For the labeling issue, I moved the test spec farther up in the sequence to prevent labels from shifting around. Once this code is merged, I'll do a quick sniff test for bugs (see Pivotal Tracker story). I also noticed that in the Cypress test with shared points, the angle measurement seems to fluctuate. While I addressed this in the code, I’m considering removing this check, as the labels on the line segments seem to work well. I’m wondering if Cypress may have caught a bug here, so I’ll do some manual testing to determine if it’s a Cypress quirk or something more. |
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 good, I Approve - i.e., I don't need to review this again. However, I made several comments, of which the one about:
expect(angleText).not.to.equal('90...
(my second comment below) should at least be looked at, and changed if I am correct about it.
// Also check that the angle label has changed from its original value | ||
geometryToolTile.getAngleAdornment().should(($label) => { | ||
const angleText = $label.text(); | ||
expect(angleText).not.to.equal('90'); // 90° was the original value |
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.
Shouldn't this be:
expect(angleText).not.to.equal('90°');
including the degree sign (°), or am I missing something? Alternatively, you could use ".not.contain('90')".
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.
Does not appear that this was resolved.
The matching test before the point was moved (line 268) is
geometryToolTile.getGraphPointLabel().contains('90°').should('exist');
So this should be the opposite of that, eg
expect(angleText).not.contains('90°');
I went ahead and checked in the fix since it was tiny & I wanted to test it anyway.
// Verify that the angle has decreased by 1 degree | ||
cy.get('@initialAngle').then((initialAngle) => { | ||
const newAngle = initialAngle - 1; | ||
geometryToolTile.getGraphPointLabel().contains(`${newAngle}°`).should('exist'); // Check if angle decreased by 1 degree |
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.
As above for cx & cy, you could change this to check that the value is less, rather than a specific value; however, if you do, you would need to parse out (i.e. remove) the degree sign (°) from the new value returned by getGraphPointLabel(), so that you can compare integers.
de63367
to
25742dc
Compare
…com/concord-consortium/collaborative-learning into 187809206-automation-polygon-points
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.
This looks great! 👍
// Also check that the angle label has changed from its original value | ||
geometryToolTile.getAngleAdornment().should(($label) => { | ||
const angleText = $label.text(); | ||
expect(angleText).not.to.equal('90'); // 90° was the original value |
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.
Does not appear that this was resolved.
The matching test before the point was moved (line 268) is
geometryToolTile.getGraphPointLabel().contains('90°').should('exist');
So this should be the opposite of that, eg
expect(angleText).not.contains('90°');
I went ahead and checked in the fix since it was tiny & I wanted to test it anyway.
Pull Request: Automation for Creating Polygons from Existing Points
Pivotal Tracker Story: #187809206
Description:
This PR introduces Cypress tests for automating the process of creating polygons from existing points. The tests include the following steps:
Questions:
geometry.spec.ts
or one of the table tile tests?I have put in the PR to avoid further rebase issues, but please don't hesitate to ask any questions. Thank you!
Changes Included: