I made an app that fits a linear regression model to salary data, then reports on how heavily the model weights each of five pieces of employee information to predict salaries.
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.
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.
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.
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.
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.