Issues
- relocate ui-testing platform tests to platform-coreUITEST-22Resolved issue: UITEST-22Zak Burke
- RFC: Think through re-usable card components for specific kinds of dataSTSMACOM-214Resolved issue: STSMACOM-214Mike Taylor
- SearchAndSort: Consider replacing ui-${moduleName}.resultCountSTSMACOM-108Resolved issue: STSMACOM-108Zak Burke
- Keyboard shortcut/command system.STRIPES-559Resolved issue: STRIPES-559Khalilah Gambrell
- "Page-based" routing vs "Overlay" or "Layer" routing.STRIPES-537Resolved issue: STRIPES-537
- Choose between TypeScript and FlowSTRIPES-519Resolved issue: STRIPES-519
- CONSIDER moving all Stripes libraries into a monorepoSTRIPES-503Resolved issue: STRIPES-503Mike Taylor
- Mechanism to indicate dependencies to gather translations fromSTCOR-414Resolved issue: STCOR-414Jason Skomorowski
- Per-app historySTCOR-215Resolved issue: STCOR-215
- Leveldown issues / hard-source-webpack-pluginSTCOR-210Resolved issue: STCOR-210
- Iterative move to New React Context APISTCOR-208Resolved issue: STCOR-208Roman Ruiz-Esparza
- UI: Resizeable PanesSTCOM-657Resolved issue: STCOM-657John Coburn
- Support manual ordering of ListsSTCOM-312Resolved issue: STCOM-312
- Eliminate structures directorySTCOM-277Resolved issue: STCOM-277Jeffrey Cherewaty
- Set up RFC labelSTCOM-265Resolved issue: STCOM-265John Coburn
- Should RMB enable FolioLog4j2LogDelegate by default?RMB-212
- RFC - handling of cross-module URL'sFOLIO-2088
- Expose next-major features/migration through npm pre-releases.FOLIO-1704
- RFC Routing RefactorFOLIO-1694Resolved issue: FOLIO-1694John Coburn
- Revise FOLIO release and deployment processFOLIO-1450Anton Emelianov
- SPIKE: consider pre-release syntax for UI module snapshotsFOLIO-1415
- SPIKE: Design/Discuss OverridesFOLIO-1332Resolved issue: FOLIO-1332Kurt Nordstrom
relocate ui-testing platform tests to platform-core
Description
Environment
Potential Workaround
blocks
relates to
Checklist
hideTestRail: Results
Activity
Zak BurkeSeptember 6, 2018 at 12:32 PM
ui-testing
has been renamed to stripes-testing
and the contents of tests
moved from this repository to platform-core
. Thus, this repository can now function solely as a test framework without any dependencies on UI modules, and integration tests which do depend on multiple UI modules are located in a platform which already includes them.
Mike TaylorAugust 28, 2018 at 2:33 PM
I'm in favour – though I don't feel strongly about, and could be argued around if others disagree.
Jira (the issue tracker) would have no problems at all with ui-testing
being renamed stripes-testing
. Probably one piece of config would need tweaking. could do it in his sleep.
Matt JonesAugust 28, 2018 at 2:30 PM
As noted by on Slack today:
Aside; it's probably a bug that ui-testing is so named, since the ui-* prefix otherwise indicates a Stripes module. Ought to be called something like stripes-testing.
And given we will need to release ui-testing#framework-only branch on its own,
We will then release a version of ui-testing that is the framework-only and update the dependency in stripes-cli which is currently pointing to a branch.
perhaps we do so under a new repo, stripes-testing, and deprecate ui-testing in the process. This may simplify releases going forward. Would this cause any headaches from issue tracking or other perspectives?
My first thought with renaming "ui-testing" is that all the current ui-* modules test directories are already named as such (/test/ui-testing), but this is minor. The directories would not have to change.
I don't mean to further extend scope here, but if this is something we should do, this seems to be the appropriate time to do so.
John MalconianAugust 27, 2018 at 6:45 PMEdited
I copied the latest changes (as of Aug 27) to ui-testing/tests/*.js from master to 'platform-core@FOLIO-1344-jenkins' and modified the scripts to use the UI testing context (uiTestCtx). Also did some basic linting. I think there is an outstanding PR on ui-testing that is not accounted for yet which consists of migrating new_proxy.js from ui-users to the platform suite of tests.
https://github.com/folio-org/ui-testing/pull/67
Once outstanding PRs are merged, we may want to consider making the repo read-only or perhaps designate one or two people who can make changes.
I need to finish testing of the CI changes required to invoke the UI integration tests during the nightly builds from platform core (currently run from ui-testing). Once that is complete, we need to update migrate folio-testing-platform for nightly builds to platform-complete. After that, all further UI integration test updates can be made to platform-core. We will then release a version of ui-testing that is the framework-only and update the dependency in stripes-cli which is currently pointing to a branch. After that, all further UI integration test updates can be made to platform-core.
Jakub SkoczenAugust 22, 2018 at 1:44 PM
reassigning to Zak while Matt is on vaca in order to enable progress on FOLIO-1358
It would be nice to see
ui-testing
have no dependencies on Stripes UI modules. It does so today becauseui-testing
is acting both as a test framework as well as the integration platform of sorts.Tests that span multiple apps would be better kept within a platform which defines those apps under test, like
folio-testing-platform
. This would leaveui-testing
's responsibility as a testing framework only.The advantage of this separation is that
ui-testing
can then be incorporated into other tools, like Stripes-CLI without pulling down the entire app ecosystem. Further, by having platform tests kept with a platform, we can define and maintain tests that may be unique to different platforms. Organizationally, this is much like how we have app tests that are kept with each app.