Fix IDE 324 : ClassCastException in DataListFragment and stabilize UI tests

[harshsomankar123-tech]

JIRA TICKET - https://catrobat.atlassian.net/browse/IDE-324
Description:
This pull request addresses a ClassCastException in DataListFragment and resolves test regressions within the FormulaEditorUndoTest. Additionally, it stabilizes UI interactions for Espresso tests involving platform popups.

Note: This pull request is a continuation of (#5171)

Detailed Changes

1. Fixed ClassCastException in DataListFragment.kt

• Issue: The variable editing logic in DataListFragment had a type-safety issue when trying to update user variables, which could lead to a ClassCastException or incorrect data types being saved.
• Solution: Added an explicit check for UserVariable types in editItem. It now intelligently tries to parse the input value as a Double first (for numeric variables) and falls back to a String if it's not a number. This ensures the underlying data model remains consistent.

2. Resolved FormulaEditorUndoTest Regressions

• Issue: The Espresso tests for Formula Editor undo were failing due to inconsistent UI states and strict equality checks on floating-point numbers.
• Solution: Added closeSoftKeyboard() calls to prevent the soft keyboard from obstructing the view during automated tests. Updated numeric assertions to use a delta comparison (assertEquals(expected, actual, 0.001)), making the tests more robust against minor precision differences in floating-point math.

3. Stabilized UI Test Interactions

• Issue: Espresso sometimes failed to find "Rename" or "Edit" buttons because they are located within platform popups (context menus).
• Solution: Modified UserDataItemRVInteractionWrapper.java to explicitly search for these buttons within the platform popup root (isPlatformPopup()). This prevents common "No Matching View" errors in UI tests.

Files Modified:

• DataListFragment.kt: Updated editField and editItem logic.
• FormulaEditorUndoTest.java: Improved test stability and assertions.
• UserDataItemRVInteractionWrapper.java: Fixed popup menu interaction logic.

Checklist for this pull request

Please review the contributing guidelines and wiki pages of this repository.

• Include the name of the Jira ticket in the PR’s title
• Include a summary of the changes plus the relevant context
• Choose the proper base branch (develop)
• Confirm that the changes follow the project’s coding guidelines
• Verify that the changes generate no compiler or linter warnings
• Perform a self-review of the changes
• Verify to commit no other files than the intentionally changed ones
• Include reasonable and readable tests verifying the added or changed behavior
• Confirm that new and existing unit tests pass locally
• Check that the commits’ message style matches the project’s guideline
• Stick to the project’s gitflow workflow
• Verify that your changes do not have any conflicts with the base branch
• After the PR, verify that all CI checks have passed
• Post a message in the catroid-stage or catroid-ide Slack channel and ask for a code reviewer

[harshsomankar123-tech]

@wslany Could you please add this PR issue to a Jira ticket? Apologies for raising the PR without linking one. If possible, may I create the ticket for this?
Thanks!

[wslany]

@wslany Could you please add this PR issue to a Jira ticket? Apologies for raising the PR without linking one. If possible, may I create the ticket for this? Thanks!

Thanks for the follow-up PR. Yes, I would be grateful if you could create the ticket for it. If you can't yet create it, let me set it up for you. I'll also look into how you can get write access to our jira.

I checked the changes and also ran the focused FormulaEditorUndoTest suite locally.

The good part first: the ClassCastException root cause analysis makes sense, and the new popup-menu test interactions (inRoot(isPlatformPopup())) are a nice stability improvement.

One thing I would still like to revisit in the production code, though, is that this seems to fix the symptom rather than the underlying type mismatch. DataListFragment is still declared as T : UserData, while UserVariable is actually UserData. The new UserData<*> cast in showEditDialog() and the UserVariable special case in editItem() avoid the current crash, but the model is still inconsistent. I think it would be safer to widen the fragment’s generic type / value handling more explicitly instead of relying on local casts.

On the tests: when I ran FormulaEditorUndoTest on this PR branch by itself, most of the suite was still red because of the already-known undo-button visibility issue on current develop. That looks expected to me, since this follow-up branch is based on develop and does not include the production undo fix from #5171. So I would evaluate this PR mainly as a follow-up to #5171, not as a standalone green fix on current develop.

So from my side:

• the test helper changes look good
• the crash fix direction is reasonable
• but I would prefer one more refinement on the DataListFragment typing rather than keeping the current cast-based workaround as-is

[harshsomankar123-tech]

Thanks for the follow-up PR. Yes, I would be grateful if you could create the ticket for it. If you can't yet create it, let me set it up for you. I'll also look into how you can get write access to our jira.

Yes, thank you! I’d appreciate that.

[harshsomankar123-tech]

One thing I would still like to revisit in the production code, though, is that this seems to fix the symptom rather than the underlying type mismatch. DataListFragment is still declared as T : UserData, while UserVariable is actually UserData. The new UserData<*> cast in showEditDialog() and the UserVariable special case in editItem() avoid the current crash, but the model is still inconsistent. I think it would be safer to widen the fragment’s generic type / value handling more explicitly instead of relying on local casts.

@wslany Thanks for the detailed feedback!

I agree that the current approach relies on a cast-based workaround. I’ll take another pass to improve the type handling in DataListFragment and make the solution more robust and type-safe.
I think we can continue this work after #5171 is merged, so we can ensure all tests are passing locally.

[Copilot]

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[harshsomankar123-tech]

@wslany @reichli , please take a look When u have Time? All 11 tests are now passing.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The assertEquals(expected, actual, delta) argument order is reversed here: the current-project value is passed as the expected parameter and the constant as the actual parameter. This won’t usually fail the test, but it makes assertion failure messages misleading. Swap the first two arguments so NEW_VARIABLE_VALUE.toDouble()/VARIABLE_VALUE.toDouble() is the expected value and the project value is the actual.

[Copilot]

Same as above: assertEquals(expected, actual, delta) has expected/actual swapped, which makes failures harder to interpret. Pass VARIABLE_VALUE.toDouble() as expected and the project value as actual.