Top-notch video tutorials for Swift developers

In this episode we take a look at the newly announced Swift Testing framework that is currently in preview. This leverages Swift Macros to make tests much more friendly to write, gives you much richer diagnostic information when tests fail, and is generally a welcome improvement over using XCTest. Keep in mind this is a preview at the time of recording and will require a snapshot toolchain of Swift.

One of the benefits we can get by programming to protocols and leaving our concrete implementations isolated, is that we enable swapping out these dependencies for different ones for use during tests. Doing so will require us to restructure our app setup a bit so we can have a completely separate AppDelegate and SceneDelegate for use in testing. With this setup we can control the environment completely. We'll setup mock dependencies that we can verify that the interaction with these dependencies is as expected.

Managing dependencies can be a pain. Unless you're using shared instances accessible everywhere, you end up having to pass along dependencies from class to class. One strategy for decoupling your types from external dependencies is to create protocols and "inject" the actual concrete implementations at runtime. This enables you to test them easily and also isolates library-specific APIs from the rest of your application. This can make switching between libraries more feasible. In this episode we'll take a look at a library called Resolver that does this. Technically it implements Service Location rather than Dependency Injection, but the result is similar.

We continue building out our little promise library, this time adding an ensure method, refactoring how we call the callback blocks, and fix a race condition issue by triggering callbacks even if the value has already been provided.

In this episode we will intercept and stub image requests to prevent our tests from making network calls when interacting with our view controller.

When running your unit tests, you may have noticed that your application continues to launch in the simulator. In this episode we'll talk about why that can be problematic and what you can do to mitigate this issue from interfering with your tests.

We continue testing our view controller, this time focusing on the UITableViewDataSource implementation. Testing the number of rows returned is easy, but we can also test that the controller returns the appropriate cell and that its outlets are configured properly.

Testing view controllers can sometimes be challenging. In this episode we will write some tests that verify a view controller loads its data properly from the API client. We will add additional tests to verify that a loading indicator is shown.

XCTAssertion functions are a foundational part of your test suite but sometimes can be too low-level. You want to know exactly why a test failed, not that "2 was not less than 1." By extracting helper methods to do assertions for you, you can give groups of assertions meaning, and make it easier to reason about your tests and why they might be failing.

When refactoring tests, you end up moving critical assertion logic outside of the test method. This can cause our tests to fail in the wrong spot. This becomes worse if multiple methods share test logic. When a test fails you want to know exactly where the failure occurred. By leveraging #file and #line expression literals we can move the failure back to where it should be, within the test method. We will also see how we can continue to use expectations outside of a test instance.

In this episode we look at Xcode's support for measuring Code Coverage, a term that describes how much of your code is exercised during a test run. Using this tool you can see where your deficiencies are and add tests as needed to cover more of your production code with tests.

In this episode we implement OHHTTPStubs, a library that can be used to intercept and stub out network calls made with URLSession. Using this technique we can avoid hitting the network for our tests. We can also simulate different responses that are difficult or impractical to simulate in a real request.

In this episode we talk about testing requests against a real API. For this we will build an app called CoinList that leverages the Crypto Compare API to fetch stats about crypto currencies.

In this episode we use mocks and stubs to setup collaborating objects to inspect the behaviors of tested objects.

In this episode we go over examples of value based testing used for easily testable systems.

Running your tests in Xcode Playgrounds can be a great way to get rapid feedback on your changes. It is a useful way of practicing testing and experimenting with APIs that you are not familiar with. In this episode we will see how to run the test suite and how to enhance the feedback we get by observing the test results as they are run.

If you did not check the box "Include Unit Tests" when first creating your project (or perhaps you want to add a separate testing target), this screencast will show the steps of how to get it set up from scratch. It also covers how to set up a scheme dedicated to building your tests, and choosing which tests to run automatically.

XCTest is a test framework built into Xcode. In this episode we'll see the mechanics of how this works, how your test bundle sits alongside your app in Xcode. We'll look at the structure of test cases, and the assertions we will use to verify behavior of our code.

We build our activity streak detection algorithm, testing it along the way with Quick and Nimble.

In this episode we allow for generating health data for use in the iOS simulator, where HealthKit data will not be available. We then create some known streaks to make the streak detection and UI decoration easier to test. We end the episode by setting up Quick and Nimble that we will use to test our streak generation algorithm.

In this episode we talk about a Swift testing framework called Quick. Quick offers a familiar BDD style syntax, some really friendly matchers, as well as support for testing asynchronous parts of our code. We'll use a Ninja class as our example, testing initialization, equality, and an asynchronous method.