Swift testing is Apple’s framework for operating unit exams 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 collection of posts that can show you how to begin utilizing Swift Testing in your initiatives.
On this put up, we’ll check out the next matters:
- Including a Swift Testing to an present mission
- Writing your first Swift take a look at
- 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 take a look at to an present mission.
Including a Swift Testing to an present mission
Including a brand new Swift Testing based mostly take a look at to an present mission is surprisingly easy. If you have already got a take a look at goal, all it’s good to do is add a brand new Swift file, import the testing framework, and begin writing your exams.
Previously, if you happen to would make a brand new take a look at file, the skeleton for what you’d put in that file appears 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 go")
}
}For those who’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 based mostly take a look at can seem like. All our exams are written within subclasses of XCTestCase, they’ll comprise setup and teardown strategies, and we write our exams in features prefixed with the phrase “take a look at”.
With Swift testing, all it’s good to do is add a brand new file, import the testing framework, and begin writing unit exams.
You needn’t configure any construct settings, you do not have to configure any mission settings – all you must do is add a brand new file and import the Testing framework, which is basically handy and lets you experiment with Swift testing in present initiatives even when the mission already makes use of XCTest.
It is good to know that Swift Testing works with packages, executables, libraries, and some other mission the place you’re utilizing Swift as you would possibly count on.
Here is what the identical skeleton appears like once we’re utilizing for Swift Testing.
import Testing
@Check func swiftTestingExample() {
// do setup
#count on(true, "This take a look at will at all times go")
// do teardown
}We don’t have to wrap our take a look at in a category, we don’t want a setup or teardown methodology, and we don’t have to 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 @Check macro utilized to a operate.
The @Check 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 features within structs or courses if we would like, however for simplicity I selected to point out it as a operate solely which works completely effectively.
Once you place your exams within an enclosing object, you continue to want to use @Check to the features that you simply need to run as your exams.
As an instance you select so as to add your exams to a category. You’ll be able to have setup and teardown logic within the initializer on 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, which means that you do not have to permit for one occasion of the category to run your entire exams.
You already know that you’ll at all times have a contemporary occasion for each single take a look at, so you may arrange in your initializer and tear down in a deinit.
For those who’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 right sort of object that you simply wish to use.
When doubtful, you are free to only use the type of object that you simply favor to make use of. If at any time limit you discover that you simply do want one thing that solely a category or struct may present, you may at all times swap and use that as a substitute.
Personally, I favor courses due to their deinit the place I can put any shared cleanup logic.
Within the subsequent part, I might prefer to take a little bit of a deeper have a look at structuring your exams 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 @Check 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 totally different from XCTest the place we needed to prefix all of our take a look at features with the phrase “take a look at”.
Writing exams with the @Check 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 can permit us to maneuver shared setup and teardown logic to their acceptable areas.
class MyTestSuite {
init() {
// do setup
print("doing setup")
}
deinit {
// do teardown
print("doing teardown")
}
@Check func testWillPass() {
print("operating passing take a look at")
#count on(true, "This take a look at will at all times go")
}
@Check func testWillFail() {
print("operating failing take a look at")
#count on(1 == 2, "This take a look at will at all times fail")
}
}The code above reveals two exams in a single take a look at suite class. In Swift testing, we name enclosing courses and structs suites, and so they can have names (which we’ll discover in one other put up). For now, know that this take a look at suite is named “MyTestSuite” (similar 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 operating 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 really run these exams in parallel as a lot as attainable, so that you would possibly really see two setups printed after one another or perhaps a setup and a operating take a look at interleave relying on how briskly every 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’ve 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’ll write in the true world, here is what it may seem like to check a easy view mannequin that is alleged to fetch knowledge for us.
class TestMyViewModel {
let viewModel = ExercisesViewModel()
@Check func testFetchExercises() async throws {
let workouts = strive await viewModel.fetchExercises()
#count on(workouts.depend > 0, "Workout routines must 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 necessary to remember although is that the truth that Swift testing makes use of separate cases for every of my exams signifies that I can not depend on any ordering or no matter of my exams, so each take a look at has to run in full isolation which is a finest observe 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 gadgets. If there are zero gadgets, the take a look at will fail as a result of the expectation for my #count on macro evaluates to false.
I might prefer 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 taking a look at along with the @Check macro, so let’s simply take a extremely temporary have a look at what sorts of macros now we have out there to us within the Swift testing framework.
Exploring the fundamentals of Swift testing syntax
You have already seen some exams, so that you’re considerably aware of the syntax. You’ll be able to acknowledge a Swift take a look at by searching for the @Check macro. The @Check macro is used to determine particular person exams, which signifies that we may give our features any identify that we would like.
You have got additionally seen the #count on macro. The #count on macro permits us to jot down our assertions within the type of expectations which are 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 take a look at.
Earlier than we take a deeper have a look at #count on, let’s take a more in-depth have a look at the @Check macro first. The @Check macro is used to sign {that a} sure operate represents a take a look at in our take a look at suite.
We will go some arguments to our @Check, 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 go take a look at traits (which I am going to cowl in one other put up), and arguments (which I am going to additionally cowl in one other put up).
Arguments are probably the most fascinating one for my part as a result of they’d mean you can really run a take a look at operate a number of occasions with totally different enter arguments. However like I mentioned, that’s a subject for one more day…
Let’s keep on focus.
The show identify that we are able to go to a take a look at macro can be utilized a bit bit like this.
@Check("Check fetching workouts")
func testFetchExercises() async throws {
let workouts = strive await viewModel.fetchExercises()
#count on(workouts.depend > 0, "Workout routines must be fetched")
}Now at any time when 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 not likely wanted, however for longer exams, it can undoubtedly be helpful to have the ability to give extra human-readable names to your exams. I’d advise that you simply use the show identify argument in your exams wherever related.
The second constructing block of Swift testing that I might like to take a look at now could be 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 that will or could not throw, or it may take a press release that can return a Boolean worth. You have already seen the Bool model in motion.
Typically you will write exams the place you need to be sure that calling a sure operate with an incorrect enter will throw a selected error. The count on macro may also deal with that.
We may give it a selected error sort 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.
@Check("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: { 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 understanding leverage Bool expectations and understanding count on thrown errors, you are already in a position to write a really highly effective exams.
In future posts, I’ll dig deeper into totally different macros and into establishing extra sophisticated exams, however I feel this could get you going with Swift testing very properly.
In Abstract
On this put up, you’ve got discovered 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 present mission is so simple as making a brand new file, importing the Swift testing framework, and writing your exams utilizing the @Check macro. The truth that it is really easy so as to add Swift testing to an present mission makes me assume that everyone ought to go and check out it out as quickly as attainable.
Writing unit exams 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 exams with Swift testing. I talked a bit bit in regards to the @Check macro and the #count on macro and the way they can be utilized to each create extra readable exams and to do extra than simply evaluating booleans.
As I’ve talked about a number of occasions, I can 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.
