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”
This weekend I built an application that allows users to rate wines. Once a user has rated some wines, the application uses k-means analysis to recommend some wines that the user hasn’t rated, but might enjoy.
Continue reading “Machine Learning: Wine Recommender”
In part 1 of this series, we discussed the relationship between data and code complexity. In part 2, we talked about some of the deficiencies datasets might have and how they happen.
Now we’ll talk about some starting points for building healthy datasets—and nursing deficient datasets to health as much as possible. It’s important to note that these starting points apply chiefly to datasets obtained via human data entry—generally via a form.
Continue reading “Diagramming Data, Part 3: Preventing and Curing Data Deficiencies”
Does hiring women or people of color affect a tech company’s bottom line?
According to some data, yes.
But so what?
Numbers like these are uplifting, but they don’t convince companies to change.
So why not?
Let’s talk about two reasons:
- We don’t definitively know why diverse leadership improves a company’s financial performance. So we can’t draw a causal link that captures leadership’s attention.
- Metrics for overall company financial performance don’t motivate lower level managers and directors. Those lower-level positions, more than the C-Suite, influence the office practices that affect company diversity numbers. But those positions don’t get individual rewards when the whole company does well.
Let’s talk about both of these.
Then we’ll talk about a more focused metric that you can use to argue for, and measure the effectiveness of, inclusion-related efforts at your company.
Bonus: our new metric will help office leadership focus on retention of women and people of color, rather than only lamenting the pipeline problem.
Continue reading “Diversity, Inclusion, and Money.”
In Part 1 of Diagramming Data, I talked about the relationship between code simplicity and the underlying data. I touched on some of the issues that organizations face with their data. Now, we’ll categorize those issues according to how easily they can be fixed.
We can take a sampling of data-related issues and place them on a continuum from easily reversible to irreversible. Some data issues can be fixed with relative ease. Others cannot be fixed without re-collecting all the data. There are also cases in the middle where we can fix issues with the data by writing complex code.
Continue reading “Diagramming Data, Part 2: Reversible and Irreversible Data Issues”
I came across an article on Firstround called ‘Forget Tech Debt…Here’s How to Build Technical Wealth.’ Andrea Goulet introduces us to some of the practices her consultancy uses to dive headfirst into legacy codebases, improve their design, and make them more maintainable.
Continue reading “Diagramming Data, Part 1: Simple Code Depends on Nice Data”
Look around your office.
If you’re in tech, I suspect I can predict what you see: lots of white faces.
We’ve known tech to be a sea of white faces for a long time. Big companies respond by sponsoring code education programs and hiring (usually white) Directors of Diversity. But the numbers aren’t changing: tech remains 95-98% white, just like it was before the Directors of Diversity got hired.
Continue reading “Bias doesn’t start with skin color.”
Lots of android devs are using this tutorial from the Google documentation to try to achieve a card flip animation, and they’re getting errors, including this one:
05-22 11:32:34.706: E/AndroidRuntime(6801): java.lang.RuntimeException: Unknown animation name: objectAnimator
There does not appear to be a definitive answer that I can find as to how to get this to work. I got it. This is the relevant portion of my build file:
You’ll notice that I mention this library in the build. I downloaded it, rather than access it on bintray, to hedge against changes in its availability, and put it in the build/libs directory of my app.
When I go to flip in/out the child fragments, my parent fragment has this click listener on my flip button:
If you’re been banging your head against this (like I did at first), please pay it forward and share this with another Android dev who might like to know.