In past posts of test-driven iOS, we have talked about instantiating view controllers with dependencies. What if we want to pass information from one view controller to the next one?
Let’s explore how we would test-drive a storyboarded iOS application that passes information from a master list view controller to a detail view controller.
Continue reading “Test-Driven iOS: Passing Information With Segues”
Once upon a time we talked about how to initialize and launch view controllers manually. We did that so we could inject our dependencies via the initializer, then unit test our view controllers independently of those components.
Then we talked about how you can inject dependencies while loading your view controllers from the storyboard, instead of manually instantiating them.
We isolate the system under test from its dependencies by using faked versions of those dependencies.
Today, we’ll look at a fake in more detail for unit testing your iOS app.
Continue reading “Test-Driven iOS: Mocking Dependencies”
When we build storyboards in iOS to wireframe and illustrate the flow of our apps, we can use segues to create transitions between screens and their elements. But if we want to unit test those transitions, we have to do it differently than we would if we were manhandling the transition programmatically with presentViewController().
So how do we do it? With three steps.
Continue reading “Test-Driven iOS: Using Segues”
In past articles about test-driven iOS, I have talked about how to resolve some challenges of unit testing an iOS app. This time I’ll talk about higher level tests that validate how the view looks and behaves when users interact with it (UI tests) as well as the app’s API requests and response handling (integration tests).
A feature test validates both the UI and the API calls of an app to document how a feature should work.
Today we’ll look at an example feature test in Swift. I’ll start by explaining the structure and purpose of feature tests, but you can skip to the code if you prefer.
Continue reading “Test-Driven iOS: Introduction to Feature Tests”
In the last Test-Driven iOS post, we talked about setting up our code and test files to allow unit testing on storyboarded apps. I mentioned that an extension of that setup could be used to take control of dependency injection inside of our apps. We’ll talk about that today.
Continue reading “Test-Driven iOS: Dependency Injection”
In this post a while back, I mentioned two options for setting up unit test-friendly dependency injection in an iOS app: dependency injection libraries and constructor injection with code-defined views. In that piece, I talked about using a code-only UI to achieve my testing goals.
Since then, I have learned a few more strategies that allow me to unit test my iOS apps while still defining the views through the storyboard, as Apple intended. Here I’ll share some of what that looks like with you.
Continue reading “Test-Driven iOS: Testing an App with Storyboard UI”
Today at lunch at Pivotal Labs, our designer Andy Detskas talked with us about some of the things he has learned about material design for Android Marshmallow.
If you’d like to see more details on the presentation than the rundown provided here, or if you’d like to follow some links to useful resources on designing for Android, you can see the slides right here.
Continue reading “Material Design: An Experience Report by Andy Detskas”
Tab layouts indicate that there are multiple pages to look at, and users can swipe them or click them to move from page to page.
Their implementation makes them difficult to test drive, so in this post we will go over how to do it.
We implement the tabs in Android by placing a TabLayout element in our activity’s view, then getting ahold of it in the Activity class code and adding tabs to it. There are limited ways to get an instance of TabLayout.Tab, and because it is a final class, it cannot be mocked.
Continue reading “Test-Driven Android: Tab Layouts”
I test-drive Android apps with some help from the Robolectric testing framework. I also get some help (usually) from the Dagger dependency injector for employing dependency injection in those apps. I define modules in dagger for injecting classes into objects that depend on them, and I define test modules that inject mock versions of those classes when I write automated tests for the objects that depend on them.
As I learned more of the Robolectric and Dagger syntax over time, I could test-drive Android app features faster and faster. I did have an issue, though; in order to inject dependencies in Android, I needed a context. The Context object in Android provides information about the application environment, and it enables app-specific stuff like launching activities and sending/receiving broadcasts.
Continue reading “Test-Driven Android: Separating Dagger from Robolectric in Test Suites”
Welcome! You’ve landed on the second post in a series of posts designed to be companion reading for Android Programming: The Big Nerd Ranch Guide, 2nd ed.
Here is the first of those posts.
BNR goes step-by-step through how to make a RecyclerView and all of the component objects that come together to make it work. The RecyclerView differs from the ListView, which is the list creation method that I have used the most in Android, so I was excited to see the RecyclerView in action. That having been said, the explanation in the book spreads out over several pages; I wanted to find something more concise to help me achieve a high-level picture of how everything talks to each other and how I might implement a RecyclerView on my own rather than copying the code verbatim in the book. I found this blog post by Ashraff Hathibelagal, which helped me sketch out a responsibility diagram for RecyclerViews to contrast with a responsibility diagram of its predecessor, the ListView/GridView:
Continue reading “Test-Driven Android: RecyclerViews”