Using Test Driven Development with Postman

The API is operational and the database is complete! All that's left now is to hook up the front end and back end, and of course to discover what bugs are lying under the surface of the application.

How I Work on APIs

The philosophy that I so want to be disciplined enough to follow is Test-Driven Development. This is a strategy that leads to highly reliable code, but it involves taking the time to write tests before you even begin.

For whatever reason, this feels like such a drag to me when I'm working on a project, but when I'm building an API it almost comes naturally to the process of working, because, using Postman, I don't write out tests, but I use the tool!

Red, Green, Refactor

Test driven development is a cycle of four steps:

1. Get it in the red
2. Get it in the green
3. Get back to the red
4. Refactor

Seems simple enough.

In step one, you write a test. Starting with the test guarantees that we have a failing test, because there's nothing for the test to well… test!

After the test is written, you generate the least amount of code possible that will produce a passing test. If you were testing a sum function, you might write a test like this

describe sum(a, b)
  it returns 6 when passed 4 and 2
    inputs: 4, 2
    result = sum(4, 2)
    assert that result is 6

Now, the least amount of code possible that produces a passing test, is not actually the complete function. It would be the following

function sum(a, b)
  return 6

Great! Our test is green.

What is the point of getting the test to pass, though when we know that this function won't work! This is a simple function, so it's a bit silly honestly to do this in this example. But, the point is that, you, as I, am a human who can make mistakes. This function is guaranteed to make the test pass if our testing framework is installed and configured correctly, and if our test is written properly.

Imagine if we were to spend hours refactoring the sum function only to realize that our test was bad!

So, now that we know we have a good test, we can add another test. This is getting back into the red

it returns 4 when passed 2 and 2
    inputs: 2, 2
    result = sum(2, 2)
    assert that result is 4

This one will fail! Now we have to come up with a way to get our function to return the correct answer to both of these questions. So, we refactor.

sum (a, b)
  return a + b

Ah, now both of our tests will pass.

If we wanted to continue the process, we would continue writing tests that put our function through the ringer. Does it handle edge cases? Does it handle the most common use cases? Keep throwing it tests until we are confident that it does what it should do.

Using Postman for TDD

When I working on an API, I like to take a similar approach with my endpoints. I am aware that we can use a testing framework to write tests that check for all of these things automatically, but frankly, I've been more excited to get the product working than I have been to set up a testing framework.

Yes, yes. Slap me on the wrist. Bad developer.

But, with Postman, I am able to hit my endpoints with quick and dirty TDD as I'm building in a way that gives me confidence that my API works as expected, while still making progress on my work that is exciting!

Getting in the Red

Since I already said that I'm not creating written tests for my API yet, getting in the red with postman looks a little different.

Instead of writing an outright test, in a new workspace, I will create a request.

And I will set it up to go to the endpoint that I want to create!

Once I test the endpoint, it will 404, because the endpoint doesn't exist yet!

Get into Green and Refactor

My first goal, to get in the green, is just to get a response back. So I will create an endpoint that just responds!

app.get('/test', (req, res) => {
  res.send('ok');
})

This will give me a 200 status code, if its set up properly! So, I'm only testing one thing at a time. Here we've confirmed the routing is accurate.

Once I've done this, then I can begin to go in and change the endpoint to handle any parameters or the request body and ensure that it's sending the proper information back.

While cycling through this process, I can create a very efficient workflow that creates a high level of assurance that the api works as expected.

This Doesn't Replace Testing

As much as I wish it did, this method doesn't entirely replace the need for some sort of testing framework. If I wanted to be sure of the functionality of my API in a single click, I have no way of doing this.

It's important to write tests that you can run as you move code from one environment to another to ensure that your code is running as you expect it to. But, for a quicker development process with high confidence in your code, this is a quick and dirty way to approach designing an API.

Check Out the Project

If you want to keep up with the changes, fork and run locally, or even suggest code changes, here’s a link to the GitHub repo!

https://github.com/nmiller15/roast

The frontend application is currently deployed on Netlify! If you want to mess around with some features and see it in action, view it on a mobile device below.

https://knowyourhomeroast.netlify.app

Note: This deployment has no backend api, so accounts and roasts are not actually saved anywhere between sessions.