Mark Struzinski

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.

This is part 4 in a multi-part series on iOS unit testing and integration testing. In the last post, we discussed setting up Core Data and the Magical Record library. This week, we’re going to set up our logic testing bundle. Let’s get started.

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.

Just a quick tip. This blog is built using Octopress. Octopress uses Jekkyl to create a static HTML site using markdown files for the content. I’ve been slowly building up some markdown specific TextExpander snippets and Keyboard Maestro macros to make things easier.

This is part 3 in a multi-part series on iOS unit testing and integration testing. In the last post, we discussed setting up SVProgressHUD.

Magical Record

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.

This is part 2 in a multi-part series on iOS unit testing and integration testing. In the last post, we discussed setting up the project and adding some dependencies with CocoaPods.

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.

I’m going to try to do a post once per month detailing my current iPhone homescreen. If it works out well, I might also do one a month for the iPad as well. Below is a screenshot of my current homescreen.