Swift testing is Apple’s framework for working unit checks in a contemporary and extra elegant means than it was with XCTest, which got here earlier than it. This put up is the primary one in a sequence of posts that may aid you begin utilizing Swift Testing in your tasks.
On this put up, we’ll check out the next matters:
- Including a Swift Testing to an present challenge
- Writing your first Swift check
- Understanding Swift Testing syntax
Let’s go forward and dive proper in and see what it takes so as to add a brand new Swift check to an present challenge.
Including a Swift Testing to an present challenge
Including a brand new Swift Testing primarily based check to an present challenge is surprisingly simple. If you have already got a check goal, all you might want to do is add a brand new Swift file, import the testing framework, and begin writing your checks.
Previously, for those who would make a brand new check file, the skeleton for what you’d put in that file appears to be like a bit like this:
import XCTest
closing class ExampleXCTest: XCTestCase {
override func setUpWithError() throws {
}
override func tearDownWithError() throws {
}
func testExample() throws {
XCTAssertTrue(true, "This check will at all times go")
}
}When 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 check can appear like. All our checks are written inside subclasses of XCTestCase, they’ll include setup and teardown strategies, and we write our checks in features prefixed with the phrase “check”.
With Swift testing, all you might want to do is add a brand new file, import the testing framework, and begin writing unit checks.
You need not configure any construct settings, you do not have to configure any challenge settings – all it’s a must to do is add a brand new file and import the Testing framework, which is actually handy and lets you experiment with Swift testing in present tasks even when the challenge already makes use of XCTest.
It is good to know that Swift Testing works with packages, executables, libraries, and some other challenge the place you’re utilizing Swift as you would possibly count on.
This is what the identical skeleton appears to be like like once we’re utilizing for Swift Testing.
import Testing
@Take a look at func swiftTestingExample() {
// do setup
#count on(true, "This check will at all times go")
// do teardown
}We don’t must wrap our check in a category, we don’t want a setup or teardown methodology, and we don’t must prefix our check with the phrase “check”.
Discover that the check that I simply confirmed is actually an @Take a look at macro utilized to a perform.
The @Take a look at macro tells the testing framework that the perform that is wrapped within the macro is a perform that incorporates a check. We will additionally put these check features inside structs or lessons if we wish, however for simplicity I selected to point out it as a perform solely which works completely nicely.
While you place your checks inside an enclosing object, you continue to want to use @Take a look at to the features that you simply wish to run as your checks.
To illustrate you select so as to add your checks to a category. You possibly can 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 check that it runs, that means that you do not have to permit for one occasion of the category to run all your checks.
You realize that you’ll at all times have a recent occasion for each single check, so you possibly can arrange in your initializer and tear down in a deinit.
When 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 select and select the proper kind of object that you simply wish to use.
When unsure, you are free to only use the form of object that you simply desire to make use of. If at any cut-off date you discover that you simply do want one thing that solely a category or struct may present, you possibly can at all times swap and use that as a substitute.
Personally, I desire 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 have a look at structuring your checks and the sorts of issues that we are able to do inside a check, so let’s dig into writing your first Swift check.
Writing your first Swift check
You’ve got simply seen your first check already. It was a free-floating perform annotated with the @Take a look at macro. Everytime you write a Swift check perform, you are going to apply the check macro to it. That is totally different from XCTest the place we needed to prefix all of our check features with the phrase “check”.
Writing checks with the @Take a look at macro is much more handy as a result of it permits us to have cleaner perform names, which I actually like.
Let’s seize the check from earlier and put that inside a category. This can enable us to maneuver shared setup and teardown logic to their acceptable places.
class MyTestSuite {
init() {
// do setup
print("doing setup")
}
deinit {
// do teardown
print("doing teardown")
}
@Take a look at func testWillPass() {
print("working passing check")
#count on(true, "This check will at all times go")
}
@Take a look at func testWillFail() {
print("working failing check")
#count on(1 == 2, "This check will at all times fail")
}
}The code above reveals two checks in a single check suite class. In Swift testing, we name enclosing lessons and structs suites, they usually can have names (which we’ll discover in one other put up). For now, know that this check suite known as “MyTestSuite” (identical to the category title).
If we run this check, we see the doing setup line print first, then we see that we’re working the passing check, adopted by the teardown. We’ll see one other setup, one other failing check, after which we’ll see one other teardown.
What’s attention-grabbing is that Swift testing will truly run these checks 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 check interleave relying on how briskly every little thing runs. It’s because Swift testing makes a separate occasion of your check suite for each check perform you will have.
Having separate situations permits us to do setup within the initializer and teardown within the de-initializer.
If we broaden this instance right here to one thing that is a little bit bit extra like what you’d write in the true world, here is what it may appear like to check a easy view mannequin that is imagined to fetch information for us.
class TestMyViewModel {
let viewModel = ExercisesViewModel()
@Take a look at func testFetchExercises() async throws {
let workouts = attempt await viewModel.fetchExercises()
#count on(workouts.rely > 0, "Workouts must be fetched")
}
}As a result of we’re making new situations 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 check and know that it’ll be cleaned up after the check runs.
That is very nice.
What’s necessary to remember although is that the truth that Swift testing makes use of separate situations for every of my checks implies that I can’t depend on any ordering or no matter of my checks, so each check has to run in full isolation which is a finest follow for unit testing anyway.
Within my check fetch workouts perform, I can simply take my let workouts and confirm that it has greater than zero objects. If there are zero objects, the check will fail as a result of the expectation for my #count on macro evaluates to false.
I might wish to zoom in a little 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 taking a look at along with the @Take a look at macro, so let’s simply take a extremely transient have a look at what sorts of macros now we have obtainable to us within the Swift testing framework.
Exploring the fundamentals of Swift testing syntax
You’ve got already seen some checks, so that you’re considerably conversant in the syntax. You possibly can acknowledge a Swift check by on the lookout for the @Take a look at macro. The @Take a look at macro is used to establish particular person checks, which implies that we can provide our features any title that we wish.
You may have additionally seen the #count on macro. The #count on macro permits us to put in writing our assertions within the type of expectations which can be going to provide us a boolean worth (true or false) and we are able to add a label that reveals us what must be introduced in case of a failing check.
Earlier than we take a deeper have a look at #count on, let’s take a more in-depth have a look at the @Take a look at macro first. The @Take a look at macro is used to sign {that a} sure perform represents a check in our check suite.
We will go some arguments to our @Take a look at, one in every of these arguments is be a show title (to make a extra human-readable model of our check). We will additionally go check traits (which I will cowl in one other put up), and arguments (which I will additionally cowl in one other put up).
Arguments are probably the most attention-grabbing one for my part as a result of they might permit you to truly run a check perform a number of occasions with totally different enter arguments. However like I mentioned, that’s a subject for an additional day…
Let’s keep on focus.
The show title that we are able to go to a check macro can be utilized a little bit bit like this.
@Take a look at("Take a look at fetching workouts")
func testFetchExercises() async throws {
let workouts = attempt await viewModel.fetchExercises()
#count on(workouts.rely > 0, "Workouts must be fetched")
}Now every time this check runs, it is going to be labeled because the human-readable check “Fetching workouts” vs the perform title. For a brief check like this, that is in all probability not likely wanted, however for longer checks, it’s going to positively be helpful to have the ability to give extra human-readable names to your checks. I might advise that you simply use the show title argument in your checks 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 may take a press release which will or might not throw, or it may take a press release that may return a Boolean worth. You’ve got already seen the Bool model in motion.
Typically you may write checks the place you wish to be sure that calling a sure perform with an incorrect enter will throw a particular error. The count on macro can even deal with that.
We can provide it a particular 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 must be thrown when no workouts are discovered",
performing: { attempt await viewModel.fetchExercises() })
}I feel these are probably the most helpful issues to know concerning the #count on macro as a result of with simply understanding the way to leverage Bool expectations and understanding the way to count on thrown errors, you are already capable of write a really highly effective checks.
In future posts, I’ll dig deeper into totally different macros and into establishing extra difficult checks, however I feel this could get you going with Swift testing very properly.
In Abstract
On this put up, you have discovered how one can get began with the Swift testing framework. You’ve got seen that including a brand new Swift check to an present challenge is so simple as making a brand new file, importing the Swift testing framework, and writing your checks utilizing the @Take a look at macro. The truth that it is really easy so as to add Swift testing to an present challenge makes me assume that everyone ought to go and take a look at it out as quickly as doable.
Writing unit checks with Swift testing feels quite a bit faster and much more elegant than it ever did with XCTest. You’ve got additionally seen the fundamentals of writing unit checks with Swift testing. I talked a little bit bit concerning the @Take a look at macro and the #count on macro and the way they can be utilized to each create extra readable checks 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 totally different options of the testing framework. However for now, I feel it is a nice introduction that hopefully will get you excited for a brand new period in testing your Swift code.
