Assert comparative locations of elements

[bendelonlee]

Use case

I'm working on a calendar app. I want to write tests asserting that after various interactions, a cursor ends up in the right place on a list, that is to say, between the right bubbles on the list. This happens to be tricky to test with unit tests and other types of testing, as bugs can occur through the interaction of a lot of moving parts. This is why I've wanted to test it using an E2E framework like maestro.

When I ran maestro hierarchy I thought this would be possible. The information I need is in the hierarchy tree. There's the bounds with x and y coordinates, which I thought I would be able to access. Then I could pass these into a script that would run a comparison of the y coordinates. But alas, while there is a copyTextFrom method I can call, there is nothing I can call through maestro api to access the bounds or any other properties of an element.

I could try using assertWithAI for this, but this feels very much like computational overkill, the wrong tool for the job. The data, the x and y bounds, are there, I just don't have access to them.

Proposal

Following your pattern of copyTextFrom, implement a copyBoundsFrom. This would enable me to write the assertions I want to write. It would also not expose much more than you're exposing.

Alternately, you could do something like copyNodeFrom or copyJsonFrom. This would give you more coverage as far as something that a future user might want to test, as well as enable me to write the assertions I'm wanting to write.

Or, in some way, expose the hierarchy object to the js scripts.

Any of these would be great!

Anything else?

No response

[linear[bot]]

MAE-352

[Fishbowler]

Wouldn't relative position selectors be sufficient for this?

- assertVisible:
    text: The Cursor
    below: Wednesday 7 January
    above: Thursday 8 January

I'm not disputing the potential utility of your proposal - either explicitly fetching element details (or implicitly when using element selectors?) would be useful. We'd want to consider some performance characteristics - what happens if someone does getNode: theRootContainer? Do we actually want to carry the entire node hierarchy forwards as a JavaScript object?