Expanded swipe to support from: -> to: #2117
Conversation
|
Thanks @NorseGaud! This looks really handy! You could certainly do an integration test, and perhaps some of the maths is unit testable? I don't know if there's a suitable place for an e2e test (i.e. I don't know if there's a suitable element to swipe on to see an effect to test against). Lemme know if you need a hand! |
|
Hey @Fishbowler I found the docs for testing. I spent a few hours trying to get an IntegrationTest, but failed to do so. it seems like
Can you recommend the approach I can take for this? Also, apologies but my developer wrote all of this new code and I can't afford to have him write tests too. I'm just not good enough at Kotlin to understand how to get this test written :( |
You can swipe from element id to the point using relative | absolute coordinates.
NorseGaud
force-pushed
the
swipe_expand
branch
from
01c7c91 to
3fa3a9e
Compare
|
This looks like an awesome and really helpful PR. Does anyone know when this will be released? |
|
Hi @c-goettert the only thing left is to add the proper tests that the maestro team wants. Unfortunately I don't have any more money for this project to have my dev do it, since we're unblocked in our fork of the code, so I can't do it. Maybe you could help? |
|
This is exactly what I needed as the RIGHT direction didn't travel far enough to get the result I wanted. I was also wondering, is it possible to due a starting point inside the id of an element, I have a large element that I wish to start swiping from the top left corner, but by default it starts from the middle. |
|
I think that this feature is very valuable and useful for many cases, it would be a pity if this work was not getting merged. Unfortunately, I am not very deeply involved in the project myself and will probably not be able to provide any tests in the near future. |
|
Hi @Fishbowler , any updates on when we could expect this to be added? |
|
Helloooooo! Bump! @Fishbowler , please let me know what's left for getting this merged in. |
|
OK, @Fishbowler I've got the tests passing: mobile-dev-inc/demo_app#6 |
| override val waitToSettleTimeoutMs: Int? = null, | ||
| ) : YamlSwipe | ||
|
|
||
| data class YamlRelativeCoordinateSwipeElement( |
There was a problem hiding this comment.
Can you add this case in YamlCommandReaderTest?
There was a problem hiding this comment.
I don't know what that means. Can you clarify?
|
Just realized E2E tests are failing, can you help checking what might be wrong there? |
Who are you asking? If me, I don't see any of the tests that fail related to my changes. Which ones? |
|
I think it's a flake. I've re-run them to find out. |
I know it's a bit mad, but the tests that prove Maestro but rely on Demo App go into Maestro, in It's all a little atypical, building an app to have 'something' under test, so that you can prove that your test framework actually tests. |
I don't understand what your point is |
|
I retract my point. |
|
I'm still super confused. 😅 I added the e2e tests as you mentioned. What is the different approach I did? |
|
With the E2E tests implemented, is this PR ready to merge? |
|
Any updates on this? |
|
We would also be super excited to check this out. It would be very helpful for our real device testing. |
7 participants
Proposed changes
In #1203, we realized all I needed to do was expand swipe a bit to support swiping on a picker wheel. Here is an example video showing how it works.
maestro-swipe++.mov
(we're writing a test suite for https://memlane.app)
This change adds
to:forfrom:definitions, allowing users to be a bit more precise (move a wheel picker by 1) sincedirectionis far too much of a swipe for my needs.Testing
See video. Can devs recommend where we should add tests for this?
Documentation
mobile-dev-inc/maestro-docs#97