🧪 test(settings): add missing tests for SettingsViewModel - #33
🧪 test(settings): add missing tests for SettingsViewModel#33SayanthRock wants to merge 1 commit into
Conversation
Co-authored-by: SayanthRock <202829406+SayanthRock@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
🤖 CodeAnt AI — Review Status
|
codeant-ai
Bot
added
the
size:M
![ai-coding-guardrails[bot]](https://avatars.githubusercontent.com/in/1202546?s=60&v=4){kind=small}
There was a problem hiding this comment.
Nice work! 😎
I didn't find anything of concern
Risk: 🟢 Low
Risk analysis
This PR adds unit tests for the SettingsViewModel and does not introduce any changes to production code or dependencies. As such, it has no forward-looking impact on security, data integrity, blast radius, reversibility, operational risk, or existing test coverage.
Did you know Zenable also supports GitLab SaaS and self-managed?
ai-coding-guardrails
Bot
added
the
zenable/risk:low
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe settings feature adds JUnit and coroutine test dependencies and introduces ChangesSettings ViewModel tests
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
| fun `initial state is Success with isDarkMode true`() { | ||
| val viewModel = SettingsViewModel() | ||
| val currentState = viewModel.uiState.value | ||
|
|
||
| assertEquals(SettingsState.Success(isDarkMode = true), currentState) |
There was a problem hiding this comment.
Suggestion: The test only verifies the ViewModel's hardcoded initial value and does not verify that the setting is consumed by the application's theme. MainActivity currently invokes RockReleaseHubTheme without passing this value, so this test can remain green while the rendered theme still follows the system setting instead of the settings screen's default. [incomplete implementation]
Severity Level: Critical 🚨
- ❌ Settings toggle does not change application colors.
- ❌ Settings screen gives false dark-mode feedback.
- ⚠️ Theme behavior remains controlled by system appearance.Steps of Reproduction ✅
1. Launch the application through `MainActivity.onCreate()` at
`app/src/main/java/com/sayanthrock/rockreleasehub/MainActivity.kt:11-16`; it wraps
`AppNavGraph()` in `RockReleaseHubTheme` without supplying the settings value.
2. Navigate to the Settings destination registered at
`app/src/main/java/com/sayanthrock/rockreleasehub/AppNavGraph.kt:91-93`, which renders
`SettingsScreen()`.
3. Toggle the Dark Mode switch at
`feature-settings/src/main/java/com/sayanthrock/rockreleasehub/feature/settings/SettingsScreen.kt:28-33`;
this only calls `SettingsViewModel.toggleDarkMode()`.
4. Observe that `SettingsViewModel` changes its in-memory state at
`feature-settings/src/main/java/com/sayanthrock/rockreleasehub/feature/settings/SettingsViewModel.kt:15-18`,
but `RockReleaseHubTheme` still selects `darkTheme` from `isSystemInDarkTheme()` by
default at
`core-designsystem/src/main/java/com/sayanthrock/rockreleasehub/core/designsystem/theme/Theme.kt:37-49`.
The added test at lines 9-13 remains green while the rendered application theme does not
change.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** feature-settings/src/test/java/com/sayanthrock/rockreleasehub/feature/settings/SettingsViewModelTest.kt
**Line:** 9:13
**Comment:**
*Incomplete Implementation: The test only verifies the ViewModel's hardcoded initial value and does not verify that the setting is consumed by the application's theme. `MainActivity` currently invokes `RockReleaseHubTheme` without passing this value, so this test can remain green while the rendered theme still follows the system setting instead of the settings screen's default.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| fun `toggleDarkMode changes isDarkMode from true to false`() { | ||
| val viewModel = SettingsViewModel() | ||
|
|
||
| // Initial state is true | ||
| assertEquals(SettingsState.Success(isDarkMode = true), viewModel.uiState.value) | ||
|
|
||
| // Toggle | ||
| viewModel.toggleDarkMode() | ||
|
|
||
| // State should now be false | ||
| assertEquals(SettingsState.Success(isDarkMode = false), viewModel.uiState.value) | ||
| } | ||
|
|
||
| @Test | ||
| fun `toggleDarkMode changes isDarkMode from false to true`() { | ||
| val viewModel = SettingsViewModel() | ||
|
|
||
| // Toggle to false | ||
| viewModel.toggleDarkMode() | ||
| assertEquals(SettingsState.Success(isDarkMode = false), viewModel.uiState.value) | ||
|
|
||
| // Toggle back to true | ||
| viewModel.toggleDarkMode() | ||
| assertEquals(SettingsState.Success(isDarkMode = true), viewModel.uiState.value) |
There was a problem hiding this comment.
Suggestion: These tests cover only an in-memory StateFlow transition within one ViewModel instance. They do not verify that toggling changes the actual application theme or survives ViewModel/activity recreation, so they provide false confidence for the user-visible dark-mode behavior, which is currently not connected to RockReleaseHubTheme or persisted through DataStore. [incomplete implementation]
Severity Level: Critical 🚨
- ❌ Dark-mode preference resets after ViewModel recreation.
- ❌ Process recreation loses the user's setting.
- ⚠️ Toggle tests provide incomplete feature coverage.Steps of Reproduction ✅
1. Open the Settings screen through the route at
`app/src/main/java/com/sayanthrock/rockreleasehub/AppNavGraph.kt:92`; its switch invokes
`toggleDarkMode()` at
`feature-settings/src/main/java/com/sayanthrock/rockreleasehub/feature/settings/SettingsScreen.kt:28-33`.
2. Toggle the switch and confirm the added tests pass because
`SettingsViewModel.toggleDarkMode()` updates only `_uiState.value` at
`feature-settings/src/main/java/com/sayanthrock/rockreleasehub/feature/settings/SettingsViewModel.kt:15-18`.
3. Recreate the ViewModel, such as after its owning navigation entry or process is
recreated, by constructing a new `SettingsViewModel`; its initializer at
`SettingsViewModel.kt:11-13` always restores `SettingsState.Success(isDarkMode = true)`.
4. Inspect the feature's available persistence dependency at
`feature-settings/build.gradle.kts:42` and the source usage found in the module: no
DataStore read or write is connected to this ViewModel. The tests at lines 17-40 therefore
verify only one transient instance and cannot detect loss of the user's preference or its
missing connection to `RockReleaseHubTheme`.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** feature-settings/src/test/java/com/sayanthrock/rockreleasehub/feature/settings/SettingsViewModelTest.kt
**Line:** 17:40
**Comment:**
*Incomplete Implementation: These tests cover only an in-memory `StateFlow` transition within one ViewModel instance. They do not verify that toggling changes the actual application theme or survives ViewModel/activity recreation, so they provide false confidence for the user-visible dark-mode behavior, which is currently not connected to `RockReleaseHubTheme` or persisted through DataStore.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix1 participant
User description
🎯 What: Added missing unit tests for
SettingsViewModelin thefeature-settingsmodule.📊 Coverage: Tests check the initial state of the
SettingsStateand the toggle behavior ofisDarkModestate flow values.✨ Result: Enhanced module test coverage and guarantees behavior verification of the
SettingsViewModel.PR created automatically by Jules for task 16912416769073291753 started by @SayanthRock
CodeAnt-AI Description
Add coverage for SettingsViewModel dark mode behavior
What Changed
Impact
✅ Verified default dark mode state✅ Verified dark mode toggle behavior✅ Fewer regressions in settings💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
Summary by CodeRabbit