Currently, our components are not written in a way that makes unit testing feasible, at least partly. This lack of testability complicates the validation of our storage mechanisms and ensures robust functionality. Specifically, we need to address the issue of creating and managing encrypted files and standard files within our local storage system, which are not easily unit-testable in their current form.
Solution
To improve testability, we propose the creation of a FileHandler or similar component with methods such as createEncryptedFile, createFile, deleteFile, and exists(filename). This component should be injected into EncryptedFileStorage. While FileHandler will be non-unit-testable, it will enable unit testing of EncryptedFileStorage by allowing the injection of a mocked FileHandler and subsequent stubbing and verification of expected behavior. Additionally, we can add androidTests for FileHandler or exclude it from the code coverage in the build.gradle project file under the setupJacoco method.
Furthermore, we should mark sealed class PreferenceKey<T>(val key: Preferences.Key<T>) { key
as internal val key to prevent consumers of this module from needing to add a datastore dependency.
Additionally, we should implement a singleton KeyValueStorageFactory component with a method createStorage(name: String, type: (DataStore/SharePrefs): KeyValueStorage. The factory will maintain a Map of created storages, returning an existing storage if one with the same name and type already exists, or creating a new one if not. This approach ensures that no more than one datastore with the same name is created.
The LocalKeyValueStorage and EncryptedSharedPreferencesKeyValueStorage can than be marked as internal and should not require an @Inject constructor, as they will be created within the factory. The extension property datastore on the companion object can be moved to the class level. The factory will prefix the filenames with edu.stanford.spezi, allowing for organized and grouped files in the device explorer.
Additional context
No response
Code of Conduct
[X] I agree to follow this project's Code of Conduct and Contributing Guidelines
Problem
Currently, our components are not written in a way that makes unit testing feasible, at least partly. This lack of testability complicates the validation of our storage mechanisms and ensures robust functionality. Specifically, we need to address the issue of creating and managing encrypted files and standard files within our local storage system, which are not easily unit-testable in their current form.
Solution
To improve testability, we propose the creation of a FileHandler or similar component with methods such as createEncryptedFile, createFile, deleteFile, and exists(filename). This component should be injected into EncryptedFileStorage. While FileHandler will be non-unit-testable, it will enable unit testing of EncryptedFileStorage by allowing the injection of a mocked FileHandler and subsequent stubbing and verification of expected behavior. Additionally, we can add androidTests for FileHandler or exclude it from the code coverage in the build.gradle project file under the setupJacoco method.
Furthermore, we should mark
sealed class PreferenceKey<T>(val key: Preferences.Key<T>) {key as internal val key to prevent consumers of this module from needing to add a datastore dependency.Additionally, we should implement a singleton KeyValueStorageFactory component with a method createStorage(name: String, type: (DataStore/SharePrefs): KeyValueStorage. The factory will maintain a Map of created storages, returning an existing storage if one with the same name and type already exists, or creating a new one if not. This approach ensures that no more than one datastore with the same name is created.
The LocalKeyValueStorage and EncryptedSharedPreferencesKeyValueStorage can than be marked as internal and should not require an @Inject constructor, as they will be created within the factory. The extension property datastore on the companion object can be moved to the class level. The factory will prefix the filenames with edu.stanford.spezi, allowing for organized and grouped files in the device explorer.
Additional context
No response
Code of Conduct