From the course: API Testing and Validation

Prioritizing your endpoints

From the course: API Testing and Validation

Prioritizing your endpoints

- [Instructor] Now that you've collected your endpoints, you're probably overwhelmed. You have so many endpoints, so many different parameters, and so many different payloads and really you don't know where to begin. Okay, stop and take a deep breath. The good news is that there isn't one right, single correct answer. The bad news is there isn't also one single correct answer. In short, the best way to test your API is to start thinking about the most important things people do with your API, the aspects that are changing regularly or what are the riskiest and most sensitive activities. If there are three things that every customer does, build tests for those. You want to ensure that those things work consistently with every update, release, and change. Whenever possible, do what we have in this course. Start as simple as we did and build your test step-by-step. Try a simple request, then try a simple read request, then a read/write request, then something that changes something important. It's not going to be perfect, but it's going to be a strong start and gives you a win at every step of the process. Alternatively, you can prioritize by risk. If there are specific parts of your API that are critical and must work every single time no matter what, please test it. If your API touches money, that's a good place. Just make sure you don't build loops that transfer funds over and over and over again. This may be a good time to start looking into some advanced concepts like mock objects or other testing tools, and frankly, this is a great time to consider having a sandbox for your API where changes don't talk to production environments. Whichever route you choose, it's going to feel a bit wrong. You're going to see other things you want to test. You're going to feel like you're doing it wrong, and that's entirely possible you are. Sorry, I know that's not fun to consider, but guess what? Some tests are better than no tests. Incomplete tests are better than no test. Every test you write makes your system a little bit better, a little more stable, and builds your skills and confidence. Just keep going. Now, let's tackle the final core concept here, structuring your tests.

Contents