Add unit test for sitepicker loading state

[irfano]

Closes: #

Description

This adds a unit test for the issue fixed in #12603.

• In low memory case SitePickerViewModel could be initialized but with its previous view state. This might cause isPrimaryBtnVisible=true after initialization. To mock this behavior, I set it to true manually after initialization.
• I needed to handle coroutines manually and I used StandardTestDispatcher() for this test.

Steps to reproduce

Run given initiated, when isPrimaryBtnVisible and loading state, then primary button view is not displayed test.

The tests that have been performed

given initiated, when isPrimaryBtnVisible and loading state, then primary button view is not displayed

• I have considered if this change warrants release notes and have added them to RELEASE-NOTES.txt if necessary. Use the "[Internal]" label for non-user-facing changes.

Reviewer (or Author, in the case of optional code reviews):

Please make sure these conditions are met before approving the PR, or request changes if the PR needs improvement:

• The PR is small and has a clear, single focus, or a valid explanation is provided in the description. If needed, please request to split it into smaller PRs.
• Ensure Adequate Unit Test Coverage: The changes are reasonably covered by unit tests or an explanation is provided in the PR description.
• Manual Testing: The author listed all the tests they ran, including smoke tests when needed (e.g., for refactorings). The reviewer confirmed that the PR works as expected on big (tablet) and small (phone) in case of UI changes, and no regressions are added.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce-Wear Android by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce-Wear Android
	Platform	⌚️ Wear OS
	Flavor	Jalapeno
	Build Type	Debug
	Commit	a0a673d
	Direct Download	woocommerce-wear-prototype-build-pr12614-a0a673d.apk

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce Android by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce Android
	Platform	📱 Mobile
	Flavor	Jalapeno
	Build Type	Debug
	Commit	a0a673d
	Direct Download	woocommerce-prototype-build-pr12614-a0a673d.apk

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 40.62%. Comparing base (1c2cc6c) to head (a0a673d).
Report is 21 commits behind head on trunk.

Additional details and impacted files

@@            Coverage Diff            @@
##              trunk   #12614   +/-   ##
=========================================
  Coverage     40.61%   40.62%           
- Complexity     5680     5682    +2     
=========================================
  Files          1229     1229           
  Lines         69123    69123           
  Branches       9573     9573           
=========================================
+ Hits          28074    28080    +6     
+ Misses        38466    38462    -4     
+ Partials       2583     2581    -2     

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

[AnirudhBhat]

Thanks for adding the test @irfano! LGTM. I've just shared my thoughts on removing unnecessary details from the test and it's definitely non-blocking for the merge.

[AnirudhBhat]

💡 Just sharing my thoughts here — This test doesn’t need to verify whether the primary button is visible after initialization or in low memory scenarios. The key concern is ensuring that the primary button is set to false when the screen is loading.

We can remove this line from the test and revert the changes in SitePickerViewModel to make the test simpler and easier to understand without needing to dive into those details.

[irfano]

I agree the test would be simper, but my goal was to add a unit test for this issue. If we remove these lines, we won't be able to catch the crash that occurs in low memory case. Have you already considered this?

[AnirudhBhat]

Thanks for elaborating. I'm sorry I didn't quite understand it. How does viewModel.sitePickerViewState = viewModel.sitePickerViewState.copy(isPrimaryBtnVisible = true) helps us in catching the crash in case of low memory case?

AFAIU, The crash occurred because users could click the "Continue" button while the screen was still loading, which allowed them to proceed before the sites were fully fetched, causing a null site to be passed. To fix this, we hide the "Continue" button while the screen is loading, preventing users from interacting with it prematurely. On some devices, particularly in low-memory conditions, the button may appear before all sites are fetched, but the core issue is that we allowed the button to be clicked before data was ready, not directly related to low memory.

For unit testing this logic, the main focus is to ensure that the primary button is hidden while the screen is loading, which is the key aspect to test. Right?

[irfano]

I may not have explained the issue well in the PR that I fixed it.

Normal Scenario
The "Continue" button is already hidden during the loading state. Once sites are loaded, if you put the app in the background and reopen it, you can still see the loaded sites.

Low Memory Scenario
The "Continue" button is hidden during the loading state when you first open the site picker. However, If you put the app in the background and reopen it, the screen goes into the loading state with isPrimaryBtnVisible = true value.

I suggest you to verify it with these steps:

1. Remove the line that fixes the issue

   woocommerce-android/WooCommerce/src/main/kotlin/com/woocommerce/android/ui/sitepicker/SitePickerViewModel.kt

   Line 148 in e5d1775

   isPrimaryBtnVisible = false

2. Run given initiated, when isPrimaryBtnVisible and loading state, then primary button view is not displayed test.
3. It should fail.

[irfano]

but the core issue is that we allowed the button to be clicked before data was ready, not directly related to low memory.

This is the part I couldn't make clear. The core issue is actually directly related to the low memory scenario. It works as expected in the normal case.

[AnirudhBhat]

Ah. I understand it now. Thanks for explaining it in detail. It makes sense now 👍