Swift Integration Test: What Is An Integration Test?

In this lesson

In this lesson, you will learn what an integration test is and how it differs from a unit test. The example code shows integration tests that interact with a real database.


Tap on time to skip ahead


Hello everyone. In this lesson, we’re going to talk about an integration test, and define specifically what that is. An integration test typically will test multiple components concurrently. In a unit test, we focus on a single component, but in an integration test, we focus on a subsystem or a module and all of the components working together.


For this simple example, I’m going to test the FMDBDatabaseWrapper. It interfaces with a component from a third party library that interfaces with a SQLite database. I also have another class down here called an FMDBResultSetWrapper that acts like a cursor.


I need to test that my components is able to interact with the database properly. It’s going to be a real database. We can do things like open the database, close it, start and end and commit and rollback transactions. We can execute statements and queries.


Let’s have a look at my test. I have those in a separate folder. The test that I’m going to run is called FMDBDatabaseWrapperIntegrationTest, so it’s obvious that this is an integration test. An integration test tests multiple components or a subsystem or a module and therefore it verifies that all the components work together correctly.


In this scenario, I’m testing against a real database using my FMDBDatabaseWrapper component. In the setup function for this test, I’m going to create a brand new database for every single test. Obviously, this is going to take a little bit longer than a unit test because I create a brand new database for every test. In the teardown, I want to close the database, and if I have any cursors open, I want to close those.


Let’s take a look down here at a test that’s a little more involved, this one, where I’m going to execute an update. Actually I’m going to execute a delete statement, which is a valid delete statement. I want to make sure that the delete answers the number of rows that were deleted and that that’s correct. That’s the response from the execute update function in the module that I’m testing.


When I execute an update, it answers how many rows were affected by that operation. That’s part of SQLite. In order to do this, I need to really have some tables that exist. The first thing that I do here is I call this helper function. It opens the database that was created in the setup phase. It executes an update, which creates a table with two columns, and then it inserts three rows into the table, the first row, the second row and the third row. And then it answers how many rows that it created.


If we go back to the test that I’m running where it deletes from the table, it’s going to try to delete all the rows from the table that will answer how many rows were deleted. I’m asserting that the rows that were deleted equals the number of rows that were created when I called my helper function. That’s an integration test. It’s going to verify that my whole subsystem works with a real database.


Let’s run this test. In order to do so I’m going to click on the test navigator button. I’m going to click, then, on the test that I want to run and click the button to run the test. It builds my code and my tests. It runs all of them and if I expand this, you’ll notice that it ran quite a few integration tests and they all passed. You can see that the names are quite descriptive as to what’s going on.


That’s an integration test. If we look at the logs here, we can see that in this instance they ran quickly still. Not quite as quickly as the unit tests in the other lesson but still quickly. It’s typical that integration tests take a lot longer to run. A typical set of integration tests may take minutes and depending on the complexity of the subsystem it could take many minutes. Obviously, the turn around or the feedback isn’t quite as quick but the value is that you can test that your subsystem is working with real things external to your application possible.

Additional Info

Register to get access to additional resources and info.