Hacker News Reader

Comment by jrochkind1 | Hacker News Reader

I'm not totally following the part about the simulator(s), probably because I haven't actually done mobile development before.

> When simulator interaction is needed, the CLI can connect to them via a remote mode and drive the UI via commands without having to inspect the layout or the accessibility tree. This enables blazing-fast performance and E2E tests.

I think I'm not following. Don't you still need to test the accessibility tree and layout in the actual layer the user will interact with?

View on HN

I have done some iOS development and still couldn't follow what the article was saying about the simulator. I'm actually quite interested in it, because (in my experience at least) verifying that the UI works as expected is quite painful with current LLMs and the developer tools available. They talk about building a CLI and keeping business logic isolated, ok fine, but do they still run the simulator and take screenshots to verify their work?!

indeed it's not totally clear to me if they do or not, my question too! OK, good to know it's not just something I was confused about because of lack of context!

It’s a reasonable tradeoff. Shopify uses Rails, and there’s been a long history of discussion around E2E testing in the Rails community.

In recent Rails releases, system tests, or E2E tests, are no longer enabled by default. The short version is that they’re significantly slower and more brittle. Basecamp also removed most of their E2E tests.

I don’t know what Shopify does internally, but my guess is that they’ve taken some of those lessons and are trying to apply the same thinking to mobile development too.

https://guides.rubyonrails.org/testing.html?#when-to-use-sys...

On theweb, not surprised that Rails switched from kind of encouraging people to use as many browser-automated tests (under whatever name) as possible , to trying to discourage people from using any. Rails way really likes being absolutist.

I work in Rails too, I try to keep them to a minimum, but I definitely try to do at least one happy-path test of any major page (which includes automated accessibility audit), going without them at all seems insane to me.

Forgot the source but DHH mentioned it's not all, just most. Still makes sense to have on some scenario, just not all, or the default anymore

Oh okay. "No longer enabled by default" made it sound to me like the suggestion was not to use them at all, glad I misunderstood.

Reply on news.ycombinator.com