Await grid paste success

[labkey-chrisj]

Rationale

Occasionally, tests like BiologicsSampleUpdateTest.testBulkEditThenEditInGrid fail because they assert grid content they just pasted and then navigated away from the grid page.

This adds a check to pasteFromCell that splits apart the paste content and awaits the presence of those parts in the cell selection range (which is also the paste target).
If this is too aggressive, it would be simple to make this optional/opt-in behavior instead of default behavior

Related Pull Requests

(branches for SM, Biologics don't have changes, just there to get test runs against this change)

Changes

• verify paste content parts to be present in the dom

[labkey-chrisj]

TC test results here:
Biologics https://teamcity.labkey.org/project/LabKey_Trunk_Premium_ProductSuites_Biologics?branch=awaitGridPasteSuccess&projectTab=overview&mode=builds
SM https://teamcity.labkey.org/project/LabKey_Trunk_Premium_SampleManager?branch=awaitGridPasteSuccess&buildTypeTab=overview&mode=builds

[labkey-chrisj]

Initial test pass results show failures because values like "" and " " weren't in the actual grid cell texts; I pushed a change to filter those values out of the expected set so we aren't trying to validate non-values like that. Hopefully this resolves the failures we saw in the first runs. If we get acceptable results here we can consider whether it would be best for validating like this to be opt-in (or default) behavior; if we don't it probably makes sense for it to be opt-in only or possibly not worth doing at all.

[labkey-chrisj]

Update: test results with the latest change show only error-case pastes (where an invalid value was pasted in) failing; in biologics there were just 3 tests failing as a result. Given this result I think it would probably worthwhile to opt those 3 cases out and have this sort of validation be default behavior.
If we decide to make validation opt-in-only, I think I'm going to want to update 99% of calls to this method to opt into that.

[labkey-tchad]

[...] If we decide to make validation opt-in-only, I think I'm going to want to update 99% of calls to this method to opt into that.

Assuming a successful operation is pretty typical for our helpers. doSomethingExpectingError is a common pattern for skipping validation or checking for errors after an operation. Maybe the validation could be less strict; e.g. just check that some text appeared in a cell but don't check for all text across all cells.

[labkey-chrisj]

Assuming a successful operation is pretty typical for our helpers.

Seems fair enough. I'll flip it to be opt-in, and update calling code where I suspect test failures to involve the test racing ahead of the page consuming pasted content.
I've also loosened the check to be that any of the pasted elements appears in the selection-cells, and made an alternative (which awaits all of them instead of any) publicly available

[labkey-chrisj]

One thing I could do here is get rid of the overload that causes pasteFromCell to conditionally validate and instead make the waitForPasteContent and waitForAnyPasteContent methods public as chainable method calls after pasting.

Another thing I could do is just make getSelectionCellTexts public and have tests roll their own asserts when they want or need to verify pasted content

I could also wrap the asserts in those methods with a DeferredErrorCollector so they're non-fatal

The ability to do this sort of validation/synchronization occurred to me as needed while testing early iterations of plate configuration- the grid was (at that time) not form-submitted, it was dynamic and when there was no waiting for the form-submit button to become clickable in order to leave the page, tests would routinely race ahead of the product and it was hard to know if pasted content had made it into the app or not- (it sure seemed like it wasn't, and that uncertainty seemed at odds with our objectives of creating low-noise, stable tests).
Also, because the plateSet create page doesn't wait for input to be valid before showing the form buttons (it errors if not all plate types have values), I had to wait for valid state myself to prevent tests from running ahead of paste and failing

Also, the results from running tests against this branch (with full validation) seems to show that it was the error cases (in which paste-data into a lookup cell didn't resolve anything but still visually has pasted text in it) that came up with failures. Perhaps those cells with errors don't appear in getSelectionCellTexts? This could be a useful way of diffing pasted inputs from what's actually there in non-error cells

[labkey-danield]

You have an unused method that should not be public.

[labkey-danield]

This list is not going to be modified so you can just call .toList here.
var filteredParts = Arrays.stream(contentParts).filter(a-> !a.isEmpty() && !a.equals(" ")).toList());

[labkey-danield]

It doesn't look like this method is used.
This should not be public.

[labkey-chrisj]

It is offered as an option to changing the behavior of pasteFromCell; if it's public callers can chain this method after pasting content if they want to assert that content.
Please, if you're going to press for no change and then press for no new public methods, consider that both of these options at once doesn't make sense. If the method is private and not used internally, it might as well not exist and the purpose for this whole PR is... useless

If you want to tell me what to do with the code, please let's talk about it instead of doing this in text