fix(CDVStatusBarTests): wait for native exec

[GitToTheHub]

Platforms affected

Motivation and Context

• Sometimes actions will fail due to race conditions on the testStatusBarBackgroundColor*-methods. evaluateJavaScript completes once JavaScript has executed, but cordova.exec(...) queues the native StatusBarInternal.setBackgroundColor command asynchronously. The test then immediately reads statusBarBackgroundColor, potentially before the native command runs.
• Add a reusable test helper that evaluates JavaScript and waits until Cordova exec calls queued by that JavaScript have reached native code.
• StatusBar tests now use this helper before asserting native status bar state, avoiding races where evaluateJavaScript completes before the native StatusBarInternal command has run. Also register the deviceready expectation before loading the start page.
• Generated-By: ChatGPT 5.5

Description

Testing

Checklist

• I've run the tests to see all new and existing tests pass
• I added automated test coverage as appropriate for this change
• Commit is prefixed with (platform) if this change only applies to one platform (e.g. (android))
• If this Pull Request resolves an issue, I linked to the issue in the text above (and used the correct keyword to close issues using keywords)
• I've updated the documentation if necessary

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.76%. Comparing base (ede6404) to head (1631f65).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1680   +/-   ##
=======================================
  Coverage   81.76%   81.76%           
=======================================
  Files          17       17           
  Lines        5159     5159           
=======================================
  Hits         4218     4218           
  Misses        941      941           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[dpogue]

oooh, thanks for tracking down the root cause of these random failures!

This is probably fine in the short term for this specific test case, but I wonder if it might be good to have a generic helper that waits until the command queue is empty (i.e., all pending plugin exec calls have been processed)

[GitToTheHub]

This is probably fine in the short term for this specific test case, but I wonder if it might be good to have a generic helper that waits until the command queue is empty (i.e., all pending plugin exec calls have been processed)

Would make sense. But I don't know how this could be done :)

[GitToTheHub]

I created a generic solution with the help of ChatGPT:

I replaced the StatusBar-specific wait with a generic test helper that waits for Cordova exec calls to reach native code.

The helper registers a test-only no-op plugin, appends a barrier exec call in the same JavaScript evaluation, and waits until that barrier is received natively. This avoids relying on evaluateJavaScript completion, which only confirms the JS finished running, not that the native plugin command has been processed.

I also moved the deviceready expectation before loadStartPage to avoid missing the notification if it fires quickly.