Integration Testing Overview

[00:00:00]
>> Speaker 1: Now we're ready to make some tests for our code Like with the Crowd Controllers, I've pretty much thought of all the tests we'll ever write, so we won't be writing all of those, but we will test the code for those Controllers that we wrote

[00:00:00]
Before getting to the tests, I want to talk about testing in general, the types of tests, and why we're doing the testing that we're doing So, we're gonna be doing some Integration Testing

[00:00:00]
When it comes to production-ready APIs, you pretty much have to test your code It's like, people are using stuff in production, and if you're not testing it, I don't know how you sleep at night, especially if they're paying you

[00:00:00]
How do you know things are working Obviously, you have alerts for live things, but how do you know the code you push is doing what it's supposed to do Some of the code you interact with directly affects the money you make, like when you're talking to Stripe, so you really want to make sure that critical stuff is tested

[00:00:00]
I don't write tests just to cover all the code I write tests for confidence I want to feel good that the thing I built is working the way I intended it to work If it's not working, I'm okay accepting that I didn't write good code

[00:00:00]
What I don't want is for it to not work because it's not doing what I intended, which is different from having an intention that was wrong in the first place Integration Tests, in my opinion, give you the most confidence per line of test code for APIs compared to all the other tests out there

[00:00:00]
Let's talk about the types of tests: Unit Tests, Integration Tests, End-to-End Tests, and Snapshot Tests Unit Tests are for testing single functional methods They're super fast, but I don't have a lot of confidence with these tests because many things you're testing don't work individually—they're part of a whole system

[00:00:00]
Just because they work individually 100% of the time doesn't mean they'll work together Unit Tests don't actually test business logic; they just test that individual components are doing their jobs

[00:00:00]
Integration Tests do test business logic They take a collection of different systems and implement what a client would do when interacting with your API The confidence is extremely high because you're testing exactly what a client would do from the start of the request to the end

[00:00:00]
End-to-End Tests offer an even higher degree of confidence In our case, since we're only making an API, the integration test would be the End-to-End test because there's no UI

[00:00:00]
If we had a web app consuming this API, the End-to-End test would start on the web app—clicking, scrolling, which would then call the API Snapshot Testing is essentially Unit Testing for visual aspects of components

[00:00:00]
You take a snapshot of the UI's state, either as rendered HTML or as an actual pixel comparison It provides some confidence, but it's not as critical as testing crucial routes like handling Stripe events or reconciling refunds

[00:00:00]
For our Unit Tests, we'll test things like the hash password function Our Integration Tests will interact with the entire server, just like in Postman, but without actually turning the server on

[00:00:00]
From Express's standpoint, it'll seem like a client is interacting with it The goal of our Integration Tests is to verify: given this route, this body, these parameters, query strings, and headers, we expect to get back this status and this payload

[00:00:00]
This provides the highest degree of confidence in what the API actually does In my experience, for an API, Integration Testing will cover about 70% of your code By doing Integration Tests, you'll cover all your endpoints and most database interactions

[00:00:00]
End-to-End Testing won't necessarily cover everything, especially if you have an API serving multiple clients or purposes When writing tests, remember a few best practices: Don't leave leftover data from previous test runs, mock out third-party API calls and expensive modules, handle authentication efficiently, and be aware of potential race conditions

[00:00:00]
Most importantly, test the behavior, not the implementation details Don't just verify that a specific method was called; test whether the expected outcome occurs Write isolated tests, use descriptive test names, and test both the happy path and edge cases for every route.