cc @dpgraham about viewmatcher

👍 I like the deduplication refactoring

The last questions are these dependent tests. I particularly don't like the fact, that we perform driver.back in several tests in order to setup the view for the following tests. This might break very easily if one of such tests fails. As a possible workaround we could put such calls into finally block.

What do you think @dpgraham ?

👍 I like the deduplication refactoring

The last questions are these dependent tests. I particularly don't like the fact, that we perform driver.back in several tests in order to setup the view for the following tests. This might break very easily if one of such tests fails. As a possible workaround we could put such calls into finally block.

What do you think @dpgraham ?

I am glad you asked it. I actually tried to simulate the scenario where you fail the 1st test case and all the cases immediately after them actually fails. Then, i just followed the way it's done in other test cases.

I would be more than happy to change it and totally isolate them.
There are two solutions for this i think :

1. Add beforeEach hook and start a new session everytime. (this will increase the runtime)
2. Put them in try/finally block.

Let me know which one do you guys think is the best way to go?
Thanks.

Add beforeEach hook and start a new session everytime. (this will increase the runtime)

Not all of these tests require additional setup, so I would rather extract these, that work in the same view to a separate sub-suite and reinit the app for all such sub-suites to avoid calling driver.back in any of them in order to setup the env for following tests

Add beforeEach hook and start a new session everytime. (this will increase the runtime)

Not all of these tests require additional setup, so I would rather extract these, that work in the same view to a separate sub-suite and reinit the app for all such sub-suites to avoid calling driver.back in any of them in order to setup the env for following tests

What i understand from this is let's divide our test cases into two different files.
Supposedly,

1. find-e2e-specs-default.js -> This will contain all the test-cases for which driver initialization is required only once. (in Before hook).
2. find-e2e-specs.js -> This will contain all the test cases or suites for which driver initialization is required for all the test cases (in BeforeEach).

Is my understanding correct?

What i understand from this is let's divide our test cases into two different files.

not necessarily. We can still keep the stuff in the same file. The structure might be as following:

describe('independent tests') {
beforeEach() {
startdriver()
}
afterEach() {
quitDriver()
}

...

}

describe('dependent tests') {
before() {
startdriver()
setupView()
}
after() {
quitDriver()
}

...

}

What i understand from this is let's divide our test cases into two different files.

not necessarily. We can still keep the stuff in the same file. The structure might be as following:

describe('independent tests') {
beforeEach() {
startdriver()
}
afterEach() {
quitDriver()
}

...

}

describe('dependent tests') {
before() {
startdriver()
setupView()
}
after() {
quitDriver()
}

...

}

I really dont understand the need of creating a new driver instance every time. I actually tried to write some pseudo code for both logic

1. Putting driver.back() into finally block

• The limitation i faced here is that each and every time we do some assertion, that particular statement has to be under try/catch block. Now this will make our code nasty and unpredictable as there can be multiple nested try/catch block.

2. The approach you mentioned above. But the time for the complete execution increases by a very significant amount.

Conclusion i came upon,
Instead of initializing the driver every time for all the independent test cases, what we can do is we can just reset the app every time (for all the test cases). Now by doing that we have surety that no two test cases are dependent on each other and the app starts from the fresh state. i.e default activity & also I don't need to modify any test cases that are already existing.

`describe.only('find elements', function () {
this.timeout(MOCHA_TIMEOUT);

let driver;
before(async function () {
driver = await initSession(APIDEMO_CAPS);
});
after(async function () {
await deleteSession();
});
// this is the game changer!
this.beforeEach(async function(){
await driver.resetApp();
})
describe('elementByXPath', function () {
it('should find an element by it's xpath', async function () {
let el = await driver.elementByXPath("//*[@text='Animation']");
el.should.exist;
await el.click();
await driver.back();
});
`

resetApp call won't save time, since internally it does exactly the same thing as driver.quit/driver.init.
If it was UIA2 driver then I would use terminateApp/activateApp call, but in case of Espresso the terminateApp call on the app under test would also kill the espresso runner itself.

What we could try is to use deep linking in order to switch between views (e.g. start the corresponding intent for each view). As far as I remember in the Catalog app each entry is represented by a separate activity.

resetApp call won't save time, since internally it does exactly the same thing as driver.quit/driver.init.
If it was UIA2 driver then I would use terminateApp/activateApp call, but in case of Espresso the terminateApp call on the app under test would also kill the espresso runner itself.

What we could try is to use deep linking in order to switch between views (e.g. start the corresponding intent for each view). As far as I remember in the Catalog app each entry is represented by a separate activity.

I don't know much about deep linking and I think the demo app we are using doesn't support it.
But yes, each entry is represented by an activity. Hence we can use something like,
await driver.startActivity({ appPackage: "io.appium.android.apis", appActivity: ".content.ExternalStorage" })
I will be soon updating all the scenarios with the following code. Does that sound right approach?

Does that sound right approach?

yes it does