That’s a reasonable time I’d say, as this step’s purpose is to test your project as much as possible. For more information please read my answer below
So the thing is that yes, your tests can run in a couple of seconds if the project is compiled and there’s a fully booted iOS Simulator and your test app is installed in it.
But these are exactly the things you want to avoid when you do Continuous Integration, usually, to have a complete test as much as possible.
When you run your build on bitrise.io every build runs in a clean virtual machine. This is pretty much the same as if a new colleague would join your team with a clean MacOS install, and wants to do a full build+test on that Mac the very first time. It’d most likely take about the same time for a Swift project, even on a MacBook Pro, to compile + boot the simulator + install the app in the simulator + run the tests.
There are a couple of things you can try to speed up things, but there are always pros & cons.
- Probably the easiest one is to turn off the (Experimental) Wait to simulator boot? option of the Xcode Test step. Why is this turned on by default? Because the iOS Simulator can be unreliable, where it simply fails to properly boot for test / run the test. Would this affect your tests? Depends. Newer Xcode versions improved things quite a bit, but there are still quite a few edge cases we saw where pre-booting the iOS Simulator before starting the tests improves the reliability of the tests. But this might help, and is easy to try.
- Caching things. Now the thing about this is that you can speed up things quite a bit usually, but caching means that a previous build can affect subsequent builds. E.g. caching DerivedData where Xcode generates its build caches definitely can help, but this means that when your next build starts it’ll have the build file caches from the previous build. Did you change Xcode version between the two builds? Did you add or remove dependencies? Did you add/remove a
.gitignore? These (and many other “edge cases”) can all cause issues.
There are probably other things worth to try, you can search for tips here on discuss.bitrise.io, but unfortunately there’s no “silver bullet”. All of the “tricks” to speed up a build either can result in flaky tests (less reliable) or cause false positives & false negatives (where a previous build’s cached build intermediates either make or break the build, when with the current code it should not). Of course tread offs might worth it in your case, that’s up to you to decide, we strive to provide the most reliable solution out of the box, configured to run the fastest possible (priority is: stability > speed; but we do try to make things as fast as possible, we just don’t compromise about reliability).
P.S.: there’s one more thing which is guaranteed to speed up things, our Elite plans which use more powerful hardware (Mac Pros in case of the Mac stacks), but cost more. You can find more info about these at Pricing and Plans for Mobile DevOps - Bitrise - if you’re interested we’re happy to activate a trial.