Recognizing and understanding new terms can be a big challenge when we're trying to grow as creators.

Often an unknown term or phrase can make us feel inexperienced, or ask "should I already know this?"

(Pro Tip: No, you shouldn't. We all learn new things constantly. That's the whole point. Keep going!)

Today we'll begin trying to identify and shed light on some of the more opaque terms or phrases we might come across while learning to build our apps.

We'll approach them from the point of view of iOS/macOS developers, but the terms themselves can be used to describe things on just about any platform.

Let's begin!

Dependency Injection

We're starting with a classic. This is one of the fanciest names for one of the simplest concepts.

This is just a complicated way of describing the idea of creating some type or object, while passing in some other type or object that the first type depends on to do its work.

Here's a super simple example:

class PlacesViewController : UIViewController {
  let manager: PlacesManager

  init(manager: PlacesManager) {
    self.manager = manager
  }
}

Note how we're passing in the manager rather than accessing some PlacesManager.shared instance.

This technique has numerous implications, the most common one being around testing.

By passing in the "dependency" we give ourselves the chance to pass in a "mock" version that can behave in expected ways.

Additionally, by not using shared instances, we reduce global/shared state in our apps.

Singleton

This one is easy, and we actually just mentioned it.

A "singleton" is just a fancy word for a shared instance...

...which is just a fancy phrase for a thing that is created once and only once. They are usually long lived, and available globally via some kind of Thing.shared static property.

We covered more about singletons all the way back in Bite #4.

Modules

This is a fun one. A Swift "Module" describes the unit of code that makes up an app or framework.

Sometimes we use a module's name as a prefix for colliding type names. Like this:

// in SailingKit.framework
struct Ship { init() { } }

// in SpaceshipsKit.framework
struct Ship { init() { } }

// in an App:

import SailingKit
import SpaceshipsKit

func someFunction() {
  let ship1 = SailingKit.Ship()
  let ship2 = SpaceshipsKit.Ship()
}

Tests

Finally we'll finish up with tests. Testing itself is a fairly straightforward concept:

We write some code that doesn't go into our app. It calls the code we wrote in our app, and checks its output to make sure its working as expected.

The terms come into play when we start trying to describe types of tests.

Unit Tests

These kinds of tests usually target one small individual piece of code.

For example, we might call a function that calculates some CGRects for a layout, based on a given available container width. We'd then check that the CGRects had the expected values.

For these reasons, "Unit" testing libraries tend to provide low level assertion functions to ensure (for example) return values are what we expect.

Integration/UI Tests

These are generally a bit more broad. They tend to target code that is closer to the user's actual behavior or interactions in the app.

On iOS/macOS, these are also commonly referred to as "UI" tests, since this is the name Apple gives the feature in Xcode we use to similuate a user tapping around in our app.

Pro Tip: Learn more about "UI" Testing in these Bites

In contrast to "Unit" testing libraries, "Integration" testing libraries tend to provide tools for replicating user behavior. Tapping buttons, filling fields, and generally using the app.

That's all for today, we'll continue to explore more of these kinds of terms in future Bites!

Is there one you'd like to see more about here on LBOC? Feel free to share it using hello@littlebitesofcocoa.com!

Author's Note: 300 Bites! Never in my wildest dreams could I have imagined LBOC being such a success. My sincere thanks goes out to everyone who continues to read and subscribe each day, as well as the team at Spec and all of our wonderful sponsors who make this all possible. Here's to the next 300!