Automate Testing Your API with Postman, Newman and Jenkins (Part 4)

This is Part 4 of a four part series on how to automate testing with your APIs. The introductory blog can be found here, the second blog about Collection Runner, you can click here, and the third blog about adding Postman tests can be found here.

This is part 4 of a four part series on how to automate testing with your APIs. We will be talking about what we did in Parts 1, 2, 3, and what it all means.

Putting it all together

Let's summarize what we just did.

• We talked about how to utilize Postman and write integration scripts to test our APIs.
• We looked at Postman's Collection Runner and how that is used to run all of our endpoints and to execute each test that is defined.
• We looked at how we can use an NPM package called Newman to mimic the Collection Runner with a CLI.
• We looked at how we can run Newman on our Jenkins server by writing a small script.
• We discussed that our integration script will get executed on each build. Any time a build fails, an email alert will get sent to the team.

Where now?

Improving our continuous integration utilizing Postman, Newman and Jenkins adds another layer of quality assurance into our development life cycle. While this is a huge step in automation, we need to emphasize on the fact that your test coverage depends on the quality of your test scripts. If you have weak or outdated test scripts, automating this won't do you any good. We need to consider maintenance and writing new test scripts as part of our development. If we are disciplined in keeping these scripts current, it will benefit you in many ways. But if we don't keep up with them, they will give us a false sense of security.

Get creative, get testing, get it automated!