fix(e2e): update diary-r2-uat Scenario 2 for manual-default diary filter#1792
Merged
Conversation
Scenario 2 ("Clicking Manual chip hides automatic type chips") was clicking
the Manual mode chip when Manual is already the default — a no-op that fires
no API request. waitForResponse would time out.
Apply the same pattern already used for Scenario 10: switch to "All" first,
wait for that API response, then click Manual and await the second response.
Co-Authored-By: Claude e2e-test-engineer (Sonnet) <noreply@anthropic.com>
… diary filter The work_item_status type chip is hidden in manual mode (the new default from #1782). Switch to "All" mode first before clicking it to make automatic type chips visible, then reset request capture so only the chip-click request is measured. Co-Authored-By: Claude e2e-test-engineer (Sonnet) <noreply@anthropic.com>
…cker close The previous assertion checked pickerModal (filtered by step-1 h2) which was already absent once the flow moved to step 2, causing it to pass immediately without confirming the picker actually closed. This left a timing gap where the test's next assertion (getCreatingNewBadge) ran before React had batched and applied the setLines + closePicker state updates. Changed to pickerStep2Modal().not.toBeVisible() which polls until the step-2 modal disappears — this happens in the same React render cycle that also sets inlineCreatedBudgetLineDraft on the line card, ensuring the badge is visible by the time the assertion resolves. Fixes scenarios 16-18 in paperless-first-invoice.spec.ts (shard 5). Co-Authored-By: Claude e2e-test-engineer (Sonnet) <noreply@anthropic.com>
**Shard 12: budget-cost-basis.spec.ts (mobile)**
Replace non-retrying getAttribute('class')+toMatch() assertions with
retrying toHaveClass(/Active/i). On mobile WebKit, React's state
update after selectOption() may not have committed when getAttribute
is called. toHaveClass retries until the DOM reflects the new class.
**Shard 5: paperless-first-invoice.spec.ts Scenario 18**
Fix the invalid-amount guard setup. materializeInlineDrafts reads
financial state from the LIVE LINE (not the inline draft form), so
clearing the inline form's unitPrice field had no effect — the save
proceeded and returned a Paperless config error instead of
inlineDraftInvalid.
Fix: manipulate the LIVE LINE's inputs BEFORE queuing the draft
(while the cardMetricGrid is still visible):
- Clear unitPrice → disables unit-pricing mode (hasUnitPricing=false)
- Set totalAmount = -1 → netBase = -1 < 0 → inlineDraftInvalid fires
Co-Authored-By: Claude e2e-test-engineer (Sonnet) <noreply@anthropic.com>
Contributor
|
🎉 This PR is included in version 2.12.0-beta.3 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
e2e/tests/diary/diary-r2-uat.spec.tswhich was clicking the Manual chip when it is already the default mode — a no-op that fires no API request, causingwaitForResponseto timeoutThis is a follow-up to PR #1790 which fixed Scenarios 1, 4, and 10 but missed Scenario 2.
Test plan
🤖 Generated with Claude Code