We didn’t have a lot of unit tests, just a handful for utility classes and non-UI functionality. Bitrise then attaches that zipfile to the build! Then we can just unpack it and see what the app was doing at the time of failure.
#Critical ops testflight code zip#
Now when a build runs, it will zip up the contents of that directly, assuming anything is there.
#Critical ops testflight code zip file#
To get a zip file of these failed screenshots, just do a few small things to your project.
The filename is the test file name and the line number of the failed interaction. When a KIF test fails, it will automatically take screenshots of the application if it has been told to. Once pushed to Bitrise, they passed much more reliably. Once this change was committed, the tests began passing locally almost every time. One of our members discovered that you can speed up all animations by a factor of three with this code: We could get some failures where the tests were not expecting animations to be running, so we sprinkled in some tester().waitForAnimationsToFinish(), particularly during navigation transitions. The theory was that Bitrise workers were slower than our machines, and they failed more often during odd hours (maybe when they weren’t warmed up), so we tried loading our machines with fake work and running the tests. We started by running the tests over and over locally so we could see what was failing. They were failing frequently on our Bitrise workers, and we didn’t run them locally very often. Our integration tests are written with the KIF framework, a similar framework to UI testing, which accesses a running application using the accessibility layer. Our most immediate problem by far was that the integration tests would fail intermittently. We prioritized our build issues and got to work. The last thing a Product Owner wants to hear is that you’re going to spend a few sprints working on the build, not fixing any bugs or building features! We couldn’t spend entire sprints fixing things up, so we had to tackle our problems one at a time.
We had very few unit tests and our integration tests were done with KIF.Here’s a list of the problems and the pain we were experiencing: Apps tend to need a lot of care, given that Apple changes the rules every year, and your dependencies don’t stay still either. I started at PagerDuty during a time of revitalization of the iOS app.
0 kommentar(er)
