Feature run test under different package

[Amejia481]

close #1747

[Amejia481]

To fix the issue, I included the Dbflow annotation processor as a library dependency and I updated it in a such a way that it generates an in-memory database. Then I updated the EyeSeeTeaApplication class using the strategy pattern to allow switching between the in-memory database for instrumentation and on disk database.

[ifoche]

@Amejia481 the PR says 99 files modified. I would like to be sure where this branch was created, to be sure there's not a git problem here. IMO, there are 2 places where this branch could be created: development or v1.1_connect. If you created in v1.1_connect, you should merge the branch against v1.1_connect, and likewise for development. Can you please have a look and tell me why this huge files change?

[Amejia481]

Sure, I created from the development branch, there are so many file changes because, I added Dbflow annotation processor as a module dependency, this way I modify its code.

[Amejia481]

Hi @ifoche,
With this last commit, the in-memory functionality is completed!

Finally, we got rid of the staging build type 😛

Now every time, that we run an instrumentation test(doesn't matter which variant), it's using an in-memory database.

Also, I added a JUnit Rule for keeping the state of the in-memory DB separated from each @Testmethod, in a test class. Something pretty similar to AbsStoreTestCase.java in the new SDK project.

This test Rules don't allow to share DB state between @Test methods
For instance, if you have the following:

public class MyTestShould {

    @Rule
    public InMemoryDBFlowDataBase mInMemoryDBFlowDataBase = new InMemoryDBFlowDataBase();

    @Test
    public void test1() {
        QuestionDB question1 = new QuestionDB();
        question1.save(); //After this line id_question
        // It's going to be equals to 1
    }

    @Test
    public void test2() {
        QuestionDB question2 = new QuestionDB();
        question2.save(); //After this line id_question
        // it's still equals to 1 not 2
        // The InMemoryDBFlowDataBase cleans up for you.
    }
}

Note: For the dbflow annotation processor submodule to work, it must be checkout under
the dbflow-processor branch (that only includes the annotation processor code)

[Amejia481]

This is an example of using the JUnit rule that I mentioned in the PR.

[Amejia481]

Now, I can delete this line, because the rule is keeping the state of the DB separated, between @Test

[idelcano]

📌 References

• Issue: close Investigate whether it is possible to run the tests under a different package #1747
• Related pull-requests:

@xurxodev I merged development, tested the feature and updated the failing test.

Some notes:
We have a problem with the installed app shared preferences. Sometimes we overwrote the app`s shared preferences.

We should create a solution to avoid it.

Now:

I think the problem only happens when we use InstrumentationRegistry.getTargetContext(is a real app context) instead of InstrumentationRegistry.getContext()(is a test context).

The problem is with the getString(string id) methods get an exception when we use the test context, the get String methods only work with getTarget context.

We should separate the context used by shared preference load / save, and the context used to get translations.

At this moment this is solved with this steps:

First step: the test gets the app´s preferences one by one and saves it in memory.

Second step: The test modifies that preferences to be used by test, or add others.

Third step: when the test is finished, it restores the app preferences saving one by one the loaded preferences.

💥 How can it be tested?

Before test this branch:

If you will test this branch before merging the v1.3_connect changes:
Referral's variant has a compilation error:

To make this branch work you will modify the dynamictabadapter.
Remove the import:
import org.eyeseetea.malariacare.views.question.multiquestion.OuTreeMultiQuestionView;

and change the requireQuestionOptionValidations method to:

return true;

That problem is fixed in v1.3

To test this branch:

Use case 1:
Run the app and for example send a survey.
Run the ereferrals test.
Run the app and check the survey is not removed.

Use case 2:
Remove the app.
Run the ereferrals test.
Check database: (if you want you can do it with a breakpoint in the middle of ereferrals tests)
Check using the device file explorer if the EyeSeeTeaDB.db exist on
/data/data/org.eyeseetea.surveillance_ref_dev
databases

💾 Requires DB migration?

• Nope, we can just merge this branch.
• Yes, but we need to apply it before merging this branch.
• Yes, it's already applied.

🎨 UI changes?

• Nope, the UI remains as beautiful as it was before!
• Yeap, here you have some screenshots-

[xurxodev]

@idelcano I have created an issue to merge connect 1.3 in development and when these issues is solved then I will review this Pull Request again