Swift Unit Test: What is a Unit Test?

In this lesson

What exactly is a unit test? This lesson will answer that question for you. See some tests pass, see some tests fail. See what unit tests look like. Start your journey to learn how to write tests like a boss.

Transcript

Tap on time to skip ahead

00:10

Hello everyone. In this lesson, we’re going to learn about what specifically a unit test is. To do that, I’m going to start with what specifically we’re going to test.

00:22

In this library, I have written some code that is responsible for generating SQL and interacting with SQLite databases. It’s written in Swift but it could be any language. I have here a StatementBuilder that is responsible for building SQL statements given various types of input. I have buildDelete, buildInsert, buildSelect and buildUpdate and I’m going to write some tests against this. You’ll notice over here, that I have several other components. I’m not going to talk about those, but in reality I would want to also write tests against these classes as well.

01:00

You’ll notice that I have a folder here called SQLiteTests. I separate my tests from actual my code. I’m going to focus on this SQLStatementBuilder test because I said I was going to write tests against my SQLStatementBuilder. It’s obvious what’s being tested here.

01:18

If we have a look at the test here, the class is called SQLStatementBuilderTest and inherits from a XCTestCase. I’m using iOS in the XCTest framework that comes with Xcode. A typical test looks like this. It has typically a setup function and a teardown function where you do some things prior to each test. Then we have a bunch of tests. We’ll get into that in a second. Notice that in my setup, I create a new instance of the thing that I’m going to test. That’s going to run prior to every single one of these tests. I’m going to get a brand new instance of the builder.

02:03

Let’s focus on this first unit test as an example. I have a test, and the function’s name begins with test, the buildInsertStatement is the unit that I’m testing. I’m testing in a single method or function in the SQL statement builder, which is called buildInsertStatement. This is the scenario that I’m testing. I’m going to call it with name parameters and this is the expected outcome. I expect that when the test is done that it should generate a valid SQL insert statement.

02:36

This first line of the test is simply what I expect the builder to generate. Then I ask the builder to generate a statement, and I pass some parameters. Since my with name parameters is the scenario, I’m passing true for this argument. Then I make an assertion that something is true or equal or valid or something like that. This is a typical unit test. We do something, we make an assertion. We make a single assertion. You can look here, if you scroll down through here. I’ll do something and then I’ll assert something. My tests are very short, they run quickly. This allows me to do things and quickly get feedback on what is working and what is not working.

03:23

Let’s run this test and see what happens. I’m going to click on the test navigator button in my IDE. Most IDE’s allow you to run your unit tests from within the IDE. I’m going to select the unit test that I want to run and click the run button. You’ll notice my IDE will build, and run all the tests, and you’ll notice that it said all the tests succeeded. You’ll notice here the green arrows mean that everything succeeded.

03:49

If I look at my output, you’ll notice that, when looking at my logs, the tests ran very, very quickly. This is one of the characteristics of unit tests. You should be able to write hundreds of them and have them run in seconds. You get quick feedback and that’s one of the powerful things that you get out of unit tests.

04:11

In this scenario, I had 16 tests run and they all passed. Let’s look at what happens if something fails. In order to do that, I’m going to intentionally break some code. Since I was looking at the insert, let’s say that somebody inadvertently changed this insert, which is used by the builder. I’m going to go back to my tests and I’m going to run them. It builds and runs. You’ll notice now that I actually have two tests that are failing. If I look at those, the test runner will annotate my test and show me what happened. It said, “Hey, I expected you to generate an insert statement but it ended up looking like this.” You can clearly see what the error is. If I go back to fix that, I can see what happened exactly. This was just an inadvertent mistake that somebody made but the tests caught that. If I run that one more time then everything should be good. That’s the lesson on specifically what a unit test is.

Additional Info

Register to get access to additional resources and info.