A common issue I always run into is how to test asynchronous methods, especially networking calls. I used test the result of the calls, such as the parsing of return data, because testing the entire method proved impossible. I recently read an article from the excellent objc.io publication on asynchornous testing. By combining the patterns used in this article with some refactoring, I finally have my networking code under unit tests. Here’s what I did.
In hitting brick walls, taking road trips for work, and feeling guilty about about posting in weeks, I have reconsidered the return on investment when fully implementing logic tests. I have dealt with compiler flag issues, missing imports, manually adding .m files for compilation, and a host of other issues. After having my own doubts, and reading this post (the entire thing had me nodding my head), I’ve decided to reconsider my take on application vs unit tests. Going forward, I’m going to rework this series from the start using application tests.
They seem to be much quicker to run now. They are definitely a win in the setup/configuration department. Logic tests are much more difficult to implement.
Stay tuned for more.
In a current project, I had the need to have one specific view controller present its view in landscape orientation only. Pre-iOS 6, I would have overridden the
shouldAutoRotateToInterfaceOrientation method and returned
UIInterfaceOrientationLandscape. In iOS 6, this method is deprecated. I began researching how orientation issues should be handled going forward, and here is the way I made my specific scenario work.
Magical Record is an excellent library that compliments the Core Data framework. I’m going to assume some knowledge of Core Data here. If you need a reference, the Core Data book by Marcus Zarra is excellent, and just hit its 2nd edition. We are going to build out a very simple data model, with just one entity. This will allow us to set up the core data stack and verify that Magical Record is working.
Today, I’m going to go through setting up some initial code to use the 3rd party libraries to make sure that the libraries are working. Then we’ll set up logic tests and see what breaks with CocoaPods (spoiler: compiler errors ahead!).
I’m continuing on my task to get a full project using iOS unit tests and integration tests. My first step is to set up logic tests in Xcode. I recently watched an excellent unit testing course on Lynda. In that course, Ron Lisle goes over the advantages of using logic tests. The most compelling factor in using logic tests over application tests is speed.
I have wanted to get better at unit testing and the tooling around it for some time. I usually start out determined to get a good amount of the code covered by unit tests, and to possibly get some UI tests built around user interactions. Unfortunately, deadlines intervene, and the tests get abandoned. With my most recent project, I decided to put all of these practices in place.
I recently switched to ReadKit for reading Instapaper articles on my mac. I switched over from Read Later (no longer available). Read Later was my app of choice for a long time, but it is no longer in active development. The team was hired by Pocket, and they are working solely on the mac app now. Read Later was good, but some much needed updates were never implemented. The display for articles was frequently skewed, and the app had started to crash a lot.