Unit tests for DeveloperSettings should use mock of SharedPreferences

[artem-zinnatullin]

Currently it's more integration tests rather than a unit. For example, we don't know if it really writes values to SharedPreferences and reads them back or if it stores values just in memory.

[JcMinarro]

What do you think about to use a wrapper interface as a collaborator of DeveloperSettings instead of SharedPreferences??
With this collaborator you don't need to use robolectirc to test this class (It will be pure java), and are able to create a mock and know if DeveloperSettings is using its collaborator.
On the other hand, you could have an interface to write and other one to read, and DeveloperSettings will has two dependencies instead of the SharedPreferences. Later, on the implementation and injection step, you can use only one class that implement both interfaces if you want

[vanniktech]

+1 I also did that once

[JcMinarro]

Ok, I will do a PR with that ;)

[artem-zinnatullin]

Okay :)

[vanniktech]

@JcMinarro maybe even go one step ahead and provide a library for it then everyone could use that wrapper for sharedpreferences

I was multiple times in that point where I was close to creating one already

[JcMinarro]

@vanniktech It could be a good option. I am going to implement it on qualitymatters project and later I try to extract it on a library ;)

[lenguyenthanh]

We can also use Mock SharedPreferences with Mockito. It is good for unit test too.

[vanniktech]

What I was doing for unit tests was just a simple implementation using a HashMap. Adventage of that was that the end of the test you could verify whether the entries where in the shared preferences or not.

[lenguyenthanh]

@vanniktech +1

[JcMinarro]

We could use a spy to test it.
On the other hand, why ther is different assert on the same test and they test something that is not described on the test name??
I think that we have to split all thoses tests on two.
And later test the implementation with the spy in other test

[lenguyenthanh]

How about the idea of using this library. And then in DeveloperSetting class we have some standalone properties like:

private final BooleanPreference isStethoEnable;
private final BooleanPreference isLeakCanaryEnabled;

public boolean isStethoEnabled() {
    return isStethoEnable.get();
}

public void saveIsStethoEnabled(boolean isStethoEnabled) {
     isStethoEnable.set(isStethoEnabled);
}

In test method, we can easy to mock those things separately.

But it will look annoying if we have to many things on DeveloperSetting class.

[vanniktech]

@JcMinarro any progress on the sharedpreferences lib?