API Testing with Postman Collections in AWS CodePipeline

This post explains how to setup an AWS CodePipeline to run Postman collections for testing REST APIs using AWS CodeCommit and AWS CodeBuild.

Step 1 – Creating a Git repository with AWS CodeCommit

AWS CodeCommit is a version control service hosted by AWS. You can create, manage Git repositories on CodeCommit.

For this project, we will create a new repository named postman-sample from AWS Console > Developer Tools > CodeCommit

Picture1.png

Clone the newly created repository on your computer

Step 2 – Exporting Postman Collection

Next, we need to export the Postman collection so we can run this using newman cli

Picture2.png

Select Collection v2 option from Export Collection dialogue box and click Export

Picture3.png

Save the collection in cloned repository folder from Step 1 above

Creating buildspec file

We need to create a buildspec file to tell AWS CodeBuild how we want to run the collection. Before running the collection we need to install newman npm package in pre_build phase and then call newman cli with the collection we want to run in the build phase. We can also specify report options to generate HTML file at the end. We will upload this file to S3 after CodeBuild executes the collection:

Picture5.png

Commit & Push the collection and buildspec file to CodeCommit in master branch

You can find the collection and buildspec file used for this example at https://github.com/upgundecha/postman-sample

Step 3 – Creating an S3 Bucket to save report

Let’s create an S3 bucket to save the report file generated by the newman. We can use this file to publish the results.

From AWS Console > Storage > S3 create a new bucket named postmanreport (you will need to use a unique name). You can enable version control on S3 bucket to see historical reports.

Picture6.png

Step 4 – Creating an AWS CodeBuild Project

We will use CodeBuild to fetch the changes from CodeCommit and run the collection using newman. We already have buildspec file which has a sequence for execution.

From AWS Console > Developer Tools > CodeBuild create a project named postman-sample.

Set Source Provider as AWS CodeCommit and Repository as postman-sample:

Picture8.png

We need an environment to run the build job. Let’s configure the Ubuntu/Node.js environment and Artefacts settings as shown in below screenshot:

Picture9.png

Next, we need to configure a Service role. Create a new service role and click Continue

Picture10.png

The CodeBuild project is ready. We can test this project by manually starting the build.

Picture11.png

Step 5 – Bringing it together with AWS CodePipeline

Finally, we need to create a new AWS CodePipleine to trigger the CodeBuild when a new change is pushed to CodeCommit.

From AWS Console > Developer Tools > CodePipeline create a pipeline named postman-sample:

Picture12.pngConfigure the Source Location as AWS CodeCommit as shown in below screenshot:

Picture13.pngConfigure the Build provider as AWS CodeBuild with the CodeBuild project created in Step 4 above as shown in below screenshot:

Picture14.pngWe just want to run tests and stop there for now. We will not deploy anything in this project so we will select No Deployment option in Deploy section as shown in below screenshot:

Picture15.pngFinally, we need to configure AWS Service role as shown in below screenshot:

Picture16.pngThis will take you to IAM to define the new role:

Picture17.pngBack in CodePipeline make sure the role is specified:

Picture18.png

Review the CodePipeline configuration and create the pipeline.

Picture19.png

You will see the Pipeline created success message. You can try invoking the newly created Pipeline by clicking the Release Change button:

Picture20

Once the Pipeline is executed you will see a both Source and Build stages in Green (unless there are any errors) as shown in below screenshot:

Picture21

After a successful run, you can go and check the S3 bucket to view the report.

Picture22.png

Newman generates a nicely formatted report as shown in below screenshot:

Picture23.png

You can also configure a Lambda function or SNS to send a notification along with the report.


Adding Swagger UI support to Spring Boot REST API Project

Recently I was working on a project to build REST API using Spring Boot framework. I was looking for a way to document the service and all the operations supported by the service in an easy way. I used Swagger to document the API with really simple configurations.

Swagger does an awesome job to document your APIs directly from the source code.

The documentation and Swagger’s interactive Web UI helps users to explore the API, try supported operations with different input values and look at the output from the operation or any validations that are configured for the operation. My tester colleagues really liked this API playground.

Let’s explore steps to configure Swagger UI on an existing project.

In order to setup Swagger UI with the project, we will use Springfox library. The Springfox library enables Swagger by scanning the application, at runtime to infer API semantics based on Spring configurations, class structure and various compile time java Annotations. To get started with Springfox, we need to add following dependencies to POM (I’m using Maven for this project):

<dependency>
  <groupId>io.springfox</groupId>
  <artifactId>springfox-swagger2</artifactId>
  <version>2.6.1</version>
  <scope>compile</scope>
</dependency>
<dependency>
  <groupId>io.springfox</groupId>
  <artifactId>springfox-swagger-ui</artifactId>
  <version>2.6.1</version>
  <scope>compile</scope>
</dependency>

Next, we need to configure Docket bean in the Application class which will do the rest of the magic:

@Bean
public Docket simpleDiffServiceApi() {
  return new Docket(DocumentationType.SWAGGER_2)
  .groupName("calculator")
  .apiInfo(apiInfo())
  .select()
  .apis(RequestHandlerSelectors.any())
  .paths(PathSelectors.any())
  .build()
  .pathMapping("/");

}

This will scan the service (in this example the Calculator service request handlers). We also need to pass the API info object which is used to configure API details like Tile, Description, Version, Developer Information etc. See the Springfox docs for more configuration options.

private ApiInfo apiInfo() {
  return new ApiInfoBuilder()
  .title("A simple calculator service")
  .description("A simple calculator REST service made with Spring Boot in Java")
  .contact(new Contact("Unmesh Gundecha", "http://unmesh.me", "upgundecha@gmail.com"))
  .version("1.0")
  .build();
}

Here is the Controller class for the Calculator Service with request handler for the add operation:

@RestController
@RequestMapping("api/v1/")
public class CalculatorController {

  @Autowired
  private Calculator calculatorService;

  @RequestMapping(value = "calculator/add", method = RequestMethod.POST)
  public Result add(@RequestBody Values values) {
  int result = calculatorService.add(values.getFirstNumber(),
  values.getSecondNumber());
  return new Result(result);
  }
}

That’s it. Let’s run this service using

mvn spring-boot:run

This will launch the application. Navigate to http://localhost:8080/swagger-ui.html in a Browser window. This will show the Swagger UI with the service details. In this example it will show the Calculator service with add operation as shown in below screenshot:

swagger1

Let’s open the /api/v1/calculator/add operation. This will show details about this operation as shown in below screenshot:

swagger2

Users can try the add operation or any other operation provided by the service by submitting parameters and using the Try it out! button on the form. Here is add operation in action:

calc_service

Operations can also be further explained using various Swagger Annotations like @ApiOperation, @ApiResponse etc.

You can also define a new API from scratch in Swagger format and generate source code in over dozen different frameworks supported by the Swagger. You can play with Swagger Editor and Swagger Codegen for building new APIs at Swagger Editor