[Bulk Update Orders] Unit tests

[hafizrahman]

Part of: #13112

Description

This PR adds unit tests related to the bulk update order functionalities in the view model.

Steps to reproduce

Just ensure unit tests pass.

Testing information

n/a

The tests that have been performed

n/a

Images/gif

n/a

• 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	d1d54ec
	Direct Download	woocommerce-wear-prototype-build-pr13232-d1d54ec.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	d1d54ec
	Direct Download	woocommerce-prototype-build-pr13232-d1d54ec.apk

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 40.64%. Comparing base (4708660) to head (d1d54ec).
Report is 6 commits behind head on trunk.

Additional details and impacted files

@@             Coverage Diff              @@
##              trunk   #13232      +/-   ##
============================================
+ Coverage     40.57%   40.64%   +0.06%     
- Complexity     6383     6393      +10     
============================================
  Files          1351     1351              
  Lines         77616    77616              
  Branches      10675    10675              
============================================
+ Hits          31494    31548      +54     
+ Misses        43342    43285      -57     
- Partials       2780     2783       +3     

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

[hichamboushaba]

Outside of the scope of this PR: while reviewing this, I took a look at the code of the repository to see how we are handling partial errors, and I see that when some updates succeed and some fails, we consider the task as successful, I think we can do better here, we should tell the user that only some updates were handled (a Snackbar could be enough for this), to do this, we can use a sealed class to represent the exceptions, with a specific type that returns the number of successful and failed updates, the sealed class would also better represent the failures instead of depending on constant strings.

[hafizrahman]

Good suggestions, I agree! The way we handle partial success is not perfect at the moment. When working on it, I found it difficult to figure out the ideal UX to communicate partial success. A snackbar like you mentioned makes sense, but it feels non-actionable if we don't mention which orders fail to update. But if we mention it, and there's many failed IDs, the Snackbar won't fit (and likely not a good place to put a lot of info as well).

So it feels like we need to build an extra window for showing failures, maybe with retry functionality as well. But this gets complicated really quick when I thought about it, and I feel we'd need design direction for this.

We do log failed orders at the moment, so if needed, the information is available.

Good for future improvements or perhaps a HACK week, I'd say 👍🏼

[hichamboushaba]

A snackbar like you mentioned makes sense, but it feels non-actionable if we don't mention which orders fail to update. But if we mention it, and there's many failed IDs, the Snackbar won't fit (and likely not a good place to put a lot of info as well).

Yes, I agree the Snackbar won't be enough to list all the errors, but at least telling the user that some orders failed to update is better than telling them the update was a success, and IMO this will be a quick win since adding this will be a very simple change.
In the future though, we can work on improving the solution with a more complete solution.

[hichamboushaba]

Nice work, thanks @hafizrahman