Database is a crucial part of any softwares nowadays, especially mobile applications. We use database to store various things, such as:
- app settings: to make it consistent between app launches.
- app context: to perserve the last screen user visited. (in case the app was killed, either intentionally by the user or automatically by the system to reclaim memory)
- data from a network reponse: to better support offline mode.
- anything you want to save for later submission when network is available.
- etc and etc…
Those are the things that make an app fast and responsive and eventually useful.
Therefore, we wanna make sure that our database works correctly. No mistakes or errors is tolerant here.
But how do we achieve that?
Well, you know, we write unit tests for it.
Without 100% support for a mocking framework like OCMock, I found myself needing to get creative when building mock objects and method stubs in Swift unit tests. The great thing about testing is that you’re… well… testing things out to see if they’ll work, and I found a solution that I’m pretty happy with for now. I’m open to better ways, so leave a comment if you’ve had good results using a different design!
People tell you that you’re supposed to avoid mutable state, but how can anything happen if you never call a setter? People tell you that you’re supposed to write unit tests, but how can you test a user interaction? People tell you that you’re supposed to make your code reusable, but how can you factor it out of your enormous view controllers?
Andy Matuschak is an iOS Developer at Khan Academy, and previously helped build iOS 4.1–8 on the UIKit team. In this talk, he presents a pragmatic approach to managing complexity in inherently stateful systems.
Natasha The Robot published nice articles about Unit Testing in Swift, that explains how to implement dependency injection and introduces Quick testing framework.
Short video tutorial by Andrew Bancroft about unit testing in Swift. Shows how to test if given method was called.
Xcode Server was introduced with Xcode 5 to provide a way to perform continuous integration through the creation of bots that automate the building, analysing, testing and archiving of projects. The bots can be created in Xcode on a development Mac and then run on the server. Since this requires OS X server it is a great way to use a spare Mac you have gathering dust.
This post collects together my notes on installing and setting up the Xcode 6 service on a Yosemite OS X Server. My simple objective was to have my unit tests run each time I make a commit to a project hosted in a GitHub repository.
Series of interesting articles about iOS 8 features and Swift programming language.
So, pretty much got your head around Swift now and ready to move on to all the other new goodies in iOS 8? Here’s a series that’s been chugging along since WWDC well worth your time to read…
Continuous Integration is a must have for all modern development projects, including iOS apps. Thanks to Travis you can setup full stack CI environment in minutes. This includes not only automatic unit testing on server side, but also deploying your mobile app to testers in real time.
My sample project provides full-stack continuous integration environment. It takes advantage of free Travis-CI service.
I often hear developers new to unit testing express concern about how to deal with asynchronous operations. When I first began writing tests for Ensembles, I had the same concerns. In fact, testing asynchronous code is quite easy.