Hacker News new | past | comments | ask | show | jobs | submit login

> you're still going to get bugs at the UI layer that you can automatically test for

Surely you can prove the correctness with integration tests of your modules, and then your acceptance tests can be simple 'did the thing not show an error when we clicked on the thing, and it went to the right page'? We have 'simulate the world' 'acceptance' tests at work and they're terribly flaky, and I look back at the layered approach to testing we used in a previous job where the go-live test was to hit the landing page & search results page & check that the status code was 200.

To be fair, the kind of tests I'm proposing won't catch layout issues. But, neither will the tests you're using.




I'm not saying it's always a good idea to write exhaustive UI tests but it's nice to have the option. There's apps that I've worked on where you simple must test several business critical UI interactions haven't broken (e.g. logging in, submitting data) before you deploy. Apple getting in the way of automating this without a decent reason is annoying.

What made your UI tests so flaky? As long as the code for them isn't much beyond "enter text into text input X, click this button, you should be able to see this text" they're not too bad to write but the initial setup can be tiring.

> To be fair, the kind of tests I'm proposing won't catch layout issues.

Screenshot comparison based tools can be amazing for this as long as the way your app looks is fairly stable.

Automated testing is always a tradeoff with effort to setup vs the time you save (I'm against e.g. TDD for everything) but for complex apps and big teams it eventually pays off.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: