[Code health] Packing Structure of Unit Test

[anandwana001]

Currently, some of the files are there at the parent level of the unit test module, which can be cluttered if increases in the future (As the code grows, the files definitely increase in this area)

This can be fixed by putting each file in their respective packages. This re-structuring will not affect what packaging structure we are following in the main module, as all these are helper classes for testing purpose only.

Suggestion

unitTest/java/com/google/android/ground
├── domain
├── hilt
│   ├── BaseHiltTest
│   └── HiltExt.kt
├── mockito
│   └── MockitoKotlinHelpers.kt
├── model
├── module
│   ├── TestAuthenticationModule
│   ├── TestCoroutineDispatchersModule
│   ├── TestCoroutineScopesModule
│   ├── TestRemoteStorageModule
│   ├── TestWorkManagerModule
│   └── TestLocalDatabaseModule
├── navigation
│   └── NavigationTestHelper.kt
├── persistence
├── repository
├── system
├── ui
├── util
│   └── ResultAssertions.kt
├── view
│   ├── RecyclerViewHelper.kt
│   ├── CustomViewActions
│   └── UiTestHelper.kt
├── MainActivityTest
└── MainViewModelTest

[shobhitagarwal1612]

Can we keep all of the helpers and utils under a same directory?

It would also be nice to rename some of the helper classes to *Ext if it only contains extension functions for consistency

[anandwana001]

Can we keep all of the helpers and utils under a same directory?

So, as the helpers are moe categorised, like mockito helpers, di helpers, view helpers, so if we put all them in one, it would be hard to understand what helpers it consist of.

It would also be nice to rename some of the helper classes to *Ext if it only contains extension functions for consistency

Correct, extensions should be named with suffix Ext, nice idea.

[gino-m]

Can we keep all of the helpers and utils under a same directory?

It would also be nice to rename some of the helper classes to *Ext if it only contains extension functions for consistency

+1 to @anandwana001's comment. There are different types of ext functions / helpers in the codebase; keeping them close to where they're used helps make their scope clear. Top-level language helpers (e.g. for converting between basic types) can go somewhere under the top level, but I wouldn't imagine domain or architecture specific like HiltExt.kt also living under that directly.