-
-
Notifications
You must be signed in to change notification settings - Fork 75
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
#394 Add support for viewmatcher #516
#394 Add support for viewmatcher #516
Conversation
espresso-server/app/src/androidTest/java/io/appium/espressoserver/lib/model/ViewMatcherJson.kt
Outdated
Show resolved
Hide resolved
espresso-server/app/src/androidTest/java/io/appium/espressoserver/lib/helpers/ViewFinder.kt
Outdated
Show resolved
Hide resolved
espresso-server/app/src/androidTest/java/io/appium/espressoserver/lib/helpers/ViewFinder.kt
Outdated
Show resolved
Hide resolved
args: 'Picture getExternalFilesDir', | ||
class: 'androidx.test.espresso.matcher.ViewMatchers' | ||
})).should.eventually.exist; | ||
await driver.back(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please do not make the test dependent on each other. failure of the first test will make all the following to fail
…tween test cases
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 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.
Let me know which one do you guys think is the best way to go? |
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 |
What i understand from this is let's divide our test cases into two different files.
Is my understanding correct? |
not necessarily. We can still keep the stuff in the same file. The structure might be as following: describe('independent tests') { ... } describe('dependent tests') { ... } |
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
Conclusion i came upon, `describe.only('find elements', function () { let driver; |
resetApp call won't save time, since internally it does exactly the same thing as driver.quit/driver.init. 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. |
yes it does |
|
||
before(async function () { | ||
driver = await initSession(APIDEMO_CAPS); | ||
driver.startActivity({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this method should be awaited
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgot that. So Sorry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job. Thanks
Added support for viewmatcher which almost works similar to datamatcher.