Totally agree with you there. I try to have a few levels of testing:
- Unit - everything is mocked but the object under test
- Integration - common flows are worked through in code (eg. showing populated cells from a fixture JSON file)
- Feature - tapping through the app with the server mocked out (via recorded server responses)
- Smoke - spinning up a dev server with known data and hitting a few endpoints by tapping around the app (to ensure the "wires" or working like API keys, headers, routes, etc.)
The second two are where I see UI Testing helping the most. My comment was mostly related to the level of testing I've identified as "Smoke".
I agree; of the third party libraries KIF was the nicest to work with. The biggest issue is that it doesn't run reliably enough. When we moved our code to our CI box tests would false-negative almost 25% of the time.
I tried ticking the run loop a few different ways. But the test suite will crash and burn if you start to mess with the timing of the test host or application under test.
One issue with the XCTestExpectation note is that you can't wait for something if you don't know exactly how long it will take. Hard-coding in a timeout, essentially, can make your tests very brittle. Take, for instance, testing loading content from a local web server.
- Unit - everything is mocked but the object under test - Integration - common flows are worked through in code (eg. showing populated cells from a fixture JSON file) - Feature - tapping through the app with the server mocked out (via recorded server responses) - Smoke - spinning up a dev server with known data and hitting a few endpoints by tapping around the app (to ensure the "wires" or working like API keys, headers, routes, etc.)
The second two are where I see UI Testing helping the most. My comment was mostly related to the level of testing I've identified as "Smoke".