Swift Testing fundamentals defined – Donny Wals

Including a Swift Testing to an current undertaking

Including a brand new Swift Testing primarily based take a look at to an current undertaking is surprisingly easy. If you have already got a take a look at goal, all it’s essential do is add a brand new Swift file, import the testing framework, and begin writing your assessments.

Prior to now, should you would make a brand new take a look at file, the skeleton for what you’d put in that file seems a bit like this:

import XCTest

last class ExampleXCTest: XCTestCase {
  override func setUpWithError() throws {

  }

  override func tearDownWithError() throws {

  }

  func testExample() throws {
    XCTAssertTrue(true, "This take a look at will at all times move")
  }
}

In the event you’ve labored with unit testing earlier than, this could look acquainted to you. It’s a really plain and easy instance of what an XCTest primarily based take a look at can seem like. All our assessments are written within subclasses of XCTestCase, they’ll include setup and teardown strategies, and we write our assessments in capabilities prefixed with the phrase “take a look at”.

With Swift testing, all it’s essential do is add a brand new file, import the testing framework, and begin writing unit assessments.

You needn’t configure any construct settings, you do not have to configure any undertaking settings – all it’s important to do is add a brand new file and import the Testing framework, which is admittedly handy and means that you can experiment with Swift testing in current initiatives even when the undertaking already makes use of XCTest.

It is good to know that Swift Testing works with packages, executables, libraries, and some other undertaking the place you’re utilizing Swift as you would possibly count on.

Here is what the identical skeleton seems like after we’re utilizing for Swift Testing.

import Testing

@Take a look at func swiftTestingExample() {
    // do setup
    #count on(true, "This take a look at will at all times move")
    // do teardown
}

We don’t must wrap our take a look at in a category, we don’t want a setup or teardown technique, and we don’t must prefix our take a look at with the phrase “take a look at”.

Discover that the take a look at that I simply confirmed is basically an @Take a look at macro utilized to a operate.

The @Take a look at macro tells the testing framework that the operate that is wrapped within the macro is a operate that comprises a take a look at. We will additionally put these take a look at capabilities within structs or lessons if we wish, however for simplicity I selected to point out it as a operate solely which works completely properly.

Once you place your assessments within an enclosing object, you continue to want to use @Take a look at to the capabilities that you just need to run as your assessments.

As an example you select so as to add your assessments to a category. You may have setup and teardown logic within the initializer to your class as a result of Swift testing will make a brand new occasion of your class for each single take a look at that it runs, that means that you do not have to permit for one occasion of the category to run all your assessments.

You recognize that you will at all times have a recent occasion for each single take a look at, so you’ll be able to arrange in your initializer and tear down in a deinit.

In the event you’re working with a struct, you are able to do the identical factor, and this actually makes Swift testing a really versatile framework since you get to choose and select the proper kind of object that you just want to use.

When unsure, you are free to only use the type of object that you just want to make use of. If at any time limit you discover that you just do want one thing that solely a category or struct might present, you’ll be able to at all times change and use that as a substitute.

Personally, I want lessons due to their deinit the place I can put any shared cleanup logic.

Within the subsequent part, I might wish to take a little bit of a deeper take a look at structuring your assessments and the sorts of issues that we are able to do within a take a look at, so let’s dig into writing your first Swift take a look at.

Writing your first Swift take a look at

You have simply seen your first take a look at already. It was a free-floating operate annotated with the @Take a look at macro. Everytime you write a Swift take a look at operate, you are going to apply the take a look at macro to it. That is completely different from XCTest the place we needed to prefix all of our take a look at capabilities with the phrase “take a look at”.

Writing assessments with the @Take a look at macro is much more handy as a result of it permits us to have cleaner operate names, which I actually like.

Let’s seize the take a look at from earlier and put that within a category. This may permit us to maneuver shared setup and teardown logic to their applicable places.

class MyTestSuite {
  init() {
    // do setup
    print("doing setup")
  }

  deinit {
    // do teardown
    print("doing teardown")
  }

  @Take a look at func testWillPass() {
    print("working passing take a look at")
    #count on(true, "This take a look at will at all times move")
  }

  @Take a look at func testWillFail() {
    print("working failing take a look at")
    #count on(1 == 2, "This take a look at will at all times fail")
  }
}

The code above reveals two assessments in a single take a look at suite class. In Swift testing, we name enclosing lessons and structs suites, and so they can have names (which we’ll discover in one other publish). For now, know that this take a look at suite is known as “MyTestSuite” (identical to the category identify).

If we run this take a look at, we see the doing setup line print first, then we see that we’re working the passing take a look at, adopted by the teardown. We’ll see one other setup, one other failing take a look at, after which we’ll see one other teardown.

What’s fascinating is that Swift testing will truly run these assessments in parallel as a lot as doable, so that you would possibly truly see two setups printed after one another or perhaps a setup and a working take a look at interleave relying on how briskly every little thing runs. It is because Swift testing makes a separate occasion of your take a look at suite for each take a look at operate you have got.

Having separate cases permits us to do setup within the initializer and teardown within the de-initializer.

If we develop this instance right here to one thing that is a bit bit extra like what you’d write in the actual world, here is what it might seem like to check a easy view mannequin that is purported to fetch knowledge for us.

class TestMyViewModel {
  let viewModel = ExercisesViewModel()

  @Take a look at func testFetchExercises() async throws {
    let workouts = strive await viewModel.fetchExercises()
    #count on(workouts.depend > 0, "Workout routines needs to be fetched")
  }
}

As a result of we’re making new cases of my view mannequin, I do not actually should put the initialization of the workouts view mannequin in an initializer. I can simply write let viewModel = ExercisesViewModel() to create my ExercisesViewModel occasion proper when the category is created. And I can use it in my take a look at and know that it is going to be cleaned up after the take a look at runs.

That is very nice.

What’s vital to bear in mind although is that the truth that Swift testing makes use of separate cases for every of my assessments implies that I can not depend on any ordering or no matter of my assessments, so each take a look at has to run in full isolation which is a finest follow for unit testing anyway.

Within my take a look at fetch workouts operate, I can simply take my let workouts and confirm that it has greater than zero objects. If there are zero objects, the take a look at will fail as a result of the expectation for my #count on macro evaluates to false.

I might wish to zoom in a bit bit extra on the syntax that I am utilizing right here as a result of the #count on macro is the second macro we’re along with the @Take a look at macro, so let’s simply take a very transient take a look at what sorts of macros we’ve got accessible to us within the Swift testing framework.

Exploring the fundamentals of Swift testing syntax

You have already seen some assessments, so that you’re considerably accustomed to the syntax. You may acknowledge a Swift take a look at by searching for the @Take a look at macro. The @Take a look at macro is used to determine particular person assessments, which implies that we can provide our capabilities any identify that we wish.

You could have additionally seen the #count on macro. The #count on macro permits us to write down our assertions within the type of expectations which might be going to provide us a boolean worth (true or false) and we are able to add a label that reveals us what needs to be introduced in case of a failing take a look at.

Earlier than we take a deeper take a look at #count on, let’s take a more in-depth take a look at the @Take a look at macro first. The @Take a look at macro is used to sign {that a} sure operate represents a take a look at in our take a look at suite.

We will move some arguments to our @Take a look at, one in all these arguments is be a show identify (to make a extra human-readable model of our take a look at). We will additionally move take a look at traits (which I am going to cowl in one other publish), and arguments (which I am going to additionally cowl in one other publish).

Arguments are probably the most fascinating one in my view as a result of they’d assist you to truly run a take a look at operate a number of occasions with completely different enter arguments. However like I mentioned, that’s a subject for an additional day…

Let’s keep on focus.

The show identify that we are able to move to a take a look at macro can be utilized a bit bit like this.

@Take a look at("Take a look at fetching workouts") 
func testFetchExercises() async throws {
  let workouts = strive await viewModel.fetchExercises()
  #count on(workouts.depend > 0, "Workout routines needs to be fetched")
}

Now every time this take a look at runs, it is going to be labeled because the human-readable take a look at “Fetching workouts” vs the operate identify. For a brief take a look at like this, that is most likely probably not wanted, however for longer assessments, it can undoubtedly be helpful to have the ability to give extra human-readable names to your assessments. I might advise that you just use the show identify argument in your assessments wherever related.

The second constructing block of Swift testing that I might like to have a look at now’s the macro for anticipating a sure state to be true or false. The #count on macro can take a number of sorts of arguments. It might take a press release which will or might not throw, or it might take a press release that may return a Boolean worth. You have already seen the Bool model in motion.

Generally you will write assessments the place you need to be certain that calling a sure operate with an incorrect enter will throw a selected error. The count on macro may also deal with that.

We can provide it a selected error kind that we count on to be thrown, a human readable failure message, and the expression to carry out.

This expression is what we count on to throw the error that was outlined as the primary argument.

Right here’s an instance of utilizing #count on to check for thrown errors.

@Take a look at("Validate that an error is thrown when workouts are lacking") func throwErrorOnMissingExercises() async {
  await #count on(
    throws: FetchExercisesError.noExercisesFound, 
    "An error needs to be thrown when no workouts are discovered", 
    performing: { strive await viewModel.fetchExercises() })
}

I feel these are probably the most helpful issues to know in regards to the #count on macro as a result of with simply realizing the way to leverage Bool expectations and realizing the way to count on thrown errors, you are already capable of write a really highly effective assessments.

In future posts, I’ll dig deeper into completely different macros and into establishing extra sophisticated assessments, however I feel this could get you going with Swift testing very properly.

In Abstract

On this publish, you have realized how one can get began with the Swift testing framework. You have seen that including a brand new Swift take a look at to an current undertaking is so simple as making a brand new file, importing the Swift testing framework, and writing your assessments utilizing the @Take a look at macro. The truth that it is really easy so as to add Swift testing to an current undertaking makes me assume that everyone ought to go and check out it out as quickly as doable.

Writing unit assessments with Swift testing feels so much faster and much more elegant than it ever did with XCTest. You have additionally seen the fundamentals of writing unit assessments with Swift testing. I talked a bit bit in regards to the @Take a look at macro and the #count on macro and the way they can be utilized to each create extra readable assessments and to do extra than simply evaluating booleans.

As I’ve talked about a number of occasions, I might be writing extra posts about Swift testing, so in these posts, we’ll dig deeply into extra superior and completely different options of the testing framework. However for now, I feel this can be a nice introduction that hopefully will get you excited for a brand new period in testing your Swift code.