IDE-313 Optimize FormulaEditorComputeDialogComputationResultTest

[herbsee02]

This Pull Request optimizes the FormulaEditorComputeDialogComputationResultTest, which was an Espresso UI test class with 113 parameterizations and a runtime of 5-15 minutes.

https://catrobat.atlassian.net/browse/IDE-313

• Testing the computation dialog logic with an Instrumented Integration Test is difficult, as the high-level methods that aren't reached by Unit Tests are strongly coupled to UI components, private methods, and listener structures. Therefore, the decision was made to split concerns and shift the mathematical and operational validation to Unit Tests, while keeping some Espresso tests.
• The UI test was refactored to a minimum of 8 representative test cases, which focus on validating correct string/number/boolean representations in the ComputationResultDialog. This is especially important since this test was initially created to catch bugs related to an incorrect display of boolean values and expressions.
• The validation of the underlying business logic like operators, mathematical functions, user variables, lists, string manipulation, etc. has been migrated to fast and reliable unit tests.
  • Some of the removed UI tests were redundant and already covered by existing unit tests. Where necessary, existing test classes were refactored and extended to cover the business logic removed from the UI test.
  • Missing coverage for removed UI tests was addressed by creating new test cases and -files.

Outcome: The overall test execution runtime for the FormulaEditorComputeDialogComputationResultTest has effectively been reduced from 5-15 minutes down to 25-25 seconds and the test is now less prone to flakiness.

The decisions made for the individual test cases / test case groups can be seen in short in the following paragraph:

• listOfBracketFormulas (Keep 1/1):
  • Keep 1 test for testing bracket syntax.
• listOfNumberFormulas (Keep 1/3):
  • Keep 1 test for testing the rendering of decimal numbers.
  • Move 2 tests to Unit Tests:
    • Cover 2 old test cases by refactoring/extending FormulaTest.
    • Cover 1 old test case refactoring/extending ParserTest.
    • 1 test already covered in ParserTest.
• listOfStringFormulas (Keep 2/3):
  • Keep 2 tests for testing empty string and normal String rendering.
  • Move 1 test to Unit Tests:
    • Cover 1 old test case refactoring/extending FormulaTest.
    • 1 test already covered in ParserTest.
• listOfOperatorFormulas (Keep 0/7):
  • Move 7 tests to Unit Tests:
    • Cover 7 old test cases by refactoring/extending FormulaTest.
    • Cover 1 old test case refactoring/extending ParserTestOperators.
    • 6 tests already covered in ParserTestOperators.
• listOfBooleanOperatorFormulas (Keep 1/22):
  • Keep 1 test for testing the representation of boolean operator formula results.
  • Move 21 tests to Unit Tests:
    • Cover 21 old test cases by refactoring/extending FormulaTest.
    • 21 tests already covered in ParserTestOperators.
• listOfFunctionFormulas (Keep 0/44):
  • Move 42 tests to Unit Tests:
    • 5 tests already covered in ParserTestStringFunctions.
    • 18 tests already covered in SingleParameterFunctionParserTest.
    • 4 tests already covered in TwoParametersFunctionParserTest.
    • 3 tests already covered in ParserTestUserLists.
    • 1 test already covered in FormulaEditorColorSensorsComputeTest.
    • Cover 1 old test case by refactoring/extending TwoParametersFunctionParserTest.
    • Cover 1 old test case by refactoring/extending ParserFunctionTest.
    • Cover 2 old test cases by refactoring/extending ParserTestUserLists.
    • Cover 7 old test cases by creating new test file EmptyParameterFunctionParserTest.
    • Discard 2 old test cases as they would need integration testing and test nearly the same functionality as existing Unit Tests.
• listOfBooleanFunctionFormulas (Keep 2/9):
  • Keep 2 tests for testing the display of true and false values in the UI.
  • Move 7 tests to Unit Tests:
    • 2 old test cases already covered in ParserFunctionTest.
    • 1 old test case already covered in ParserTestUserLists.
    • 2 old test cases already covered in FormulaEditorColorSensorsComputedTest.
    • Cover 1 old test case by refactoring/extending ParserFunctionTest.
    • Cover 1 old test case by refactoring/extending FormulaEditorColorSensorsComputedTest.
    • Cover 2 old tests cases by refactoring/extending FormulaTest.
• listOfUserDataFormulas (Keep 0/13):
  • Move 13 tests to Unit Tests:
    • Cover 6 old test cases by refactoring/extending ParserTestUserVariables.
    • Cover 7 old test cases by refactoring/extending ParserTestUserLists.
    • Cover 2 old test cases by refactoring/extending FormulaTest.
• listOfBooleanUserDataFormulas (Keep 1/10):
  • Merge 8 tests into 1 test for testing the interpretation of boolean values in User Lists.
  • Move 2 tests to Unit Tests:
    • Cover 2 old tests cases by refactoring/extending FormulaTest.
    • Cover 2 old tests cases by refactoring/extending ParserTestUserVariables.
• listOfCollisionFormulas: (Keep 0/1):
  • Move 1 test to Unit Tests:
    • Cover 1 old tests case1 by refactoring/extending FormulaTest.

Your 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

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
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