Reading time ~1 minute

I knew I would eventually run into a decision regarding how to write something based on whether or not it was testable, and I’m actually not that surprised that it came early in the project. Xcode UI Testing leverages iOS’s accessibility functionality. That works great for standard UI elements, but Table Talk Quiz is SpriteKit based, and while most of the UI elements will be text labels or fields and buttons I imagined using SpriteKit to do the animations and any special effects.

Sticking with SpriteKit

My first decision was that I’m going to stick with SpriteKit. I want the option to use the effects and animations that SpriteKit provides. I can see using them for “win” and “loss” fanfare and background effects. The problem is that SpriteKit nodes aren’t testable (at least I didn’t find a way) so I wouldn’t be able to use BDD. Of course I already had a test for the start button which is an instance of UIButton which is testable. The mixing of UIKit classes and SpriteKit classes is fully supported, but I found that I have to do a little more management of the UI elements. Also, there will be a mix of UIAnimation and SpriteKit animation code which was what I was hoping to avoid, but software development is always about compromise and in this case I will sacrifice the cleanliness of a single animation type for the ability to continue my attempt at BDD.

Perils of a Family-First Software Developer

I've just survived a RIF, my skills and tool set are built around technologies that were modern 10 years ago, my interviewing skills have...… Continue reading

AWS CodeStar and TypeScript - Part 3

Published on May 28, 2017

AWS CodeStar and TypeScript - Part 2

Published on May 17, 2017