Reformat / Refactor of states in the discover Viewmodel #275
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ng the DiscoverScreenVM to use less parameters and improve the coverage in the future Still needs to be tested
… be checked deeply
…t the rest seems fine
|
Andy130604
approved these changes
May 16, 2024
There was a problem hiding this comment.
You did some amazing changes! Maybe not so visually appealing but truly useful for everyone. Your coverage is not above 80% on new code but since you are using the map I guess it isn't testable. Everything else is tested Overall really good job. Keep it up :)
app/src/main/java/com/lastaoutdoor/lasta/viewmodel/DiscoverScreenViewModel.kt
Show resolved
Hide resolved
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The issue
Previously, all the states and functions of the discoverscreen viewmodel were given as parameters to the screens using them. This made the code hard to read and maintain and had a negative impact on the general line coverage of the project. (Because the navgraph is almost untestable, adding lines there to initiate screens wasn't beneficial for us)
The solution
I fixed this for the discovery screen viewmodel by creating two data classes, one that stores all the states and one that stores all the functions called by screens. This took a lot of time to merge with main since a lot of PRs changed completely the content of certain files.
Tests
I tested as much as it was possible, but Sonar has a weird way of qualifying what is "new code". It counted in my additions a lot of part that I didn't really modify (the map screen) that blocks my line coverage at around 73. There is, for the moment, no possible ways to test this composable and since I did not change anything about it's functionalities, it should be fine and there is not much that I can do.
Additionaly, the modification I did improved the global line coverage of the project by 3%, which was already higher than 80% before.
Next
We should do that for all the viewmodel, but this time is really time consuming and comports some risks when merging