test(protocol-designer): add migration + load-save e2e tests #5369
Conversation
| const savedFile = cloneDeep(window.__lastSavedFile__) | ||
| const expected = cloneDeep(expectedExportProtocol) | ||
|
|
||
| // TODO(IL. 2020-04-03): this will change to 4.0.x soon |
There was a problem hiding this comment.
Will have to be part of #5148
Codecov Report
@@ Coverage Diff @@
## edge #5369 +/- ##
==========================================
+ Coverage 63.70% 63.95% +0.24%
==========================================
Files 1087 1087
Lines 30865 31164 +299
==========================================
+ Hits 19662 19930 +268
- Misses 11203 11234 +31
Continue to review full report at Codecov.
|
IanLondon
force-pushed
the
pd_add-migration-e2e-tests
branch
from
c3a0e1f
to
0bc1ddc
Compare
| saveAs(blob, downloadData.fileName) | ||
| if (global.Cypress) { | ||
| // HACK(IL, 2020-04-02): can't figure out a better way to do this yet | ||
| // https://docs.cypress.io/faq/questions/using-cypress-faq.html#Can-my-tests-interact-with-Redux-Vuex-data-store |
There was a problem hiding this comment.
Yeah, Ian and I discussed this a bit and I agreed that this is the best way to handle downloads right now. Cypress itself can't handle file downloads through the browser well (Selenium has the same problem). Another way we could get around this is by building a download link when we create the export that we can call cy.request() on, but that's simply another hack. This method is simpler, since we don't already generate download links, and achieves what we need (we don't need to test the browser download flow, just the contents of the file).
There was a problem hiding this comment.
Looks good, thanks for doing this @IanLondon
As discussed, I am hesitant about checking the truthiness of global.Cypress. If for some reason that variable is truthy in a user's browser then it'll mess with file download, which is obviously very problematic.
I'll defer to @dozercodes here though, maybe lets just remember to come back to this to see if we can come up with an alternative way to check if Cypress is available.
| } | ||
|
|
||
| // deepEqual won't always return a diff, Cypress doesn't fully support object diffs :( | ||
| // also Cypress doesn't seem to support logging to the console? So throwing the diff as an error instead |
There was a problem hiding this comment.
Wait, really? I was able to log to console in one of my tests, so I'm not sure why it wouldn't work here
Edit: I misunderstood. This makes sense now.
overview
In our "PD Testing Requirements for Regular Release Cadence" doc, some points we outlined were
This PR closes #5123 by recreating the v1 migration tests (disabled since v2.x.x release because labware fixtures interfered with protocol load-save process), as Cypress tests.
It also closes #5173, by ensuring that loading and saving a v3 or v4 protocol derives the same atomic
commandsfrom the data PD actually reads on import (applicationData). This prevents regressions where PD could unexpectedly generate different commands given the same step forms.This should address the PD side of #5103, but the issue still exists in Labware Creator.
I also moved protocol fixtures to
protocol-designer/fixtures/protocol/{schemaMajorVersionNum}/{fixtureName}.jsonbecause they're not only used in the load-file tests where they lived before. I thought about putting them in shared-data, but they are actually PD-specific because the shared-data fixtures don't have applicationData for PD, but the fixtures in this PR rely on applicationData.The new "result" fixtures came from loading the old fixtures into PD and migrating them. They're effectively a snapshot.
changelog
cypress-file-uploadreview requests
Cypress doesn't have much support for checking if files are downloaded or loading up the downloaded file. cypress-io/cypress#949 So this PR relies on intercepting file save if
Cypressis available, and putting the file data into a global variable that Cypress has access to.Also, Cypress doesn't always show a deep diff, it very hard to figure out what went wrong when mismatched protocols cause a
deepEqual. cypress-io/cypress#4084 So a kind-of-hack around this is using theexpectDeepEqualutility.risk assessment
Low, just PD tests