Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature run test under different package #1834

Open
wants to merge 19 commits into
base: development
Choose a base branch
from

Conversation

Amejia481
Copy link

close #1747

to define the in-memory dabatabase for instrumentation tests

Removing CustomTestRunner instead using IDatabaseHolderProviderStrategy
Removing EyeSeeTeaTestingApplication
Updating falling tests
@Amejia481
Copy link
Author

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
Copy link
Member

ifoche commented Feb 21, 2018

@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
Copy link
Author

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
Copy link
Author

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)

@@ -44,9 +38,11 @@

private final Program program = new Program("T_TZ", "low6qUS2wc9");

@Rule
public InMemoryDBFlowDataBase mInMemoryDBFlowDataBase = new InMemoryDBFlowDataBase();
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@Before
public void setUp() throws Exception {
PopulateDB.wipeDataBase();
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@idelcano
Copy link
Contributor

idelcano commented Dec 17, 2018

📌 References

@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
Copy link
Contributor

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants