From the course: JavaScript: Test-Driven Development (ES6)

Introduction to integration testing - JavaScript Tutorial

From the course: JavaScript: Test-Driven Development (ES6)

Start my 1-month free trial

Introduction to integration testing

- [Instructor] Now that we've seen how to conduct TDD with basic unit testing, it's time to move on to integration testing. Integration testing, as we discussed in a previous video, is the next step up scale-wise from unit testing. While unit testing focuses on making sure the smallest testable units of your code base, usually functions, work correctly, integration testing makes sure that the different pieces of your application interact correctly when assembled into a whole. In other words, they make sure that our code integrates correctly, hence the name. A good visual for integration testing is to picture a pipeline. And this pipeline consists of many different pipes, each of which has been rigorously unit tested to make sure it doesn't leak, doesn't rust, withstands pressure, et cetera. And that's great, but the only problem is that when we go to put all of our pipes together, we find that a lot of them don't fit and our pipeline is full of leaks, even though each of the individual segments was perfect on its own. This is how integration testing relates to unit testing. Unit testing tests the individual pieces of our application, and integration testing tests that all the pieces fit together properly into a whole. When writing unit tests, it's easy to get a false sense of security with regards to the application. Just as in the pipeline analogy, just because each individual piece seems perfect in isolation doesn't mean that the pieces will fit together well. In development terms, this means that we could have a perfect, bug free front end and a perfect, bug free back end, if you can even imagine that those are possible, but when we link them up we find that the moment we try to connect the two, the application breaks because we weren't calling the back end endpoints correctly from the front end. Another purpose for integration tests is to cover certain areas where it would be really difficult or redundant to add unit tests. As an example for those of you who are familiar with Express.js, a framework for writing servers in Node.js, how is it that we're supposed to write unit tests for the application's entry point, server.js file, where we usually specify many of the endpoints for the server? In most cases, this would involve creating a complex fake express object just to test our application, which would be a massive undertaking and provide very little real benefit. And yet, all that we really need to do to test that each of these endpoints is hooked up correctly to the rest of the server logic is to start up our server and make a request to it. And that would be an integration test. As we mentioned in a previous video, there are certain situations where unit tests don't belong. But those situations are few and far between and usually have to do with I/O operations, so don't try and use this as an excuse just to avoid writing unit tests. Another thing about integration tests is that they tend to require a little bit more work than unit tests, and this is because they often require a certain amount of setup. For example, if we're writing a function that interacts with a database, we have to create a separate database for testing, set up that database with some test data, and then make sure to reset the database after our test completes. And this all might sound a little complicated, but we'll go through how to do each of these things properly and you'll get plenty of practice as well.

Contents