All you'll need to do is take the atom.hbs file from the repo below, unzip your theme file, add the atom.hbs file to the root of the theme and zip it up again. Then for the routing and header injection, just follow the instructions in the repo.

https://github.com/JWHorner/ghost-atom-feed

Mark-up validated as of time of publishing. Let me know if you spot any validation failures in your feeds 😉

It's time to get DevOps to do the rest of the hard work for you and schedule nightly or weekly runs of your tests.

Firstly, you'll need to export your test suite as JSON as well as the environment and global JSONs. Open up your favourite text editor and change all the environment and global variable values to tokens using __{variable_name}__ (double-underscores):

{
	"id": "c2064aba-2c4d-4b8b-b025-c81af835798a",
	"name": "Contact API Production",
	"values": [
		{
			"key": "url",
			"value": "__ApiUrl__",
			"type": "default",
			"enabled": true
		},
		{
			"key": "companySearchTerm",
			"value": "__CompanySearchTerm__",
			"type": "default",
			"enabled": true
		},
		{
			"key": "companyId",
			"value": "__CompanyId__",
			"type": "default",
			"enabled": true
		}
	],
	"_postman_variable_scope": "environment",
	"_postman_exported_at": "2022-05-24T13:42:02.825Z",
	"_postman_exported_using": "Postman/9.18.2"
}

{
	"id": "6fcc71a9-8e5a-4431-86bb-0bd426788177",
	"values": [
		{
			"key": "username",
			"value": "__Username__",
			"type": "default",
			"enabled": true
		},
		{
			"key": "password",
			"value": "__Password__",
			"type": "secret",
			"enabled": true
		}
	],
	"name": "Globals",
	"_postman_variable_scope": "globals",
	"_postman_exported_at": "2022-05-23T11:01:16.517Z",
	"_postman_exported_using": "Postman/9.18.2"
}

And upload all of these files to a DevOps repo. Now we need a new build pipeline, so create one. I like the classic pipeline editor, but a YAML example is below.

The first build step is to use the "Replace Tokens" task to fill our environment and global JSON files with the correct settings for this environment. The "Target Files" should be:

**/*_environment.json
**/*_globals.json

And the "Token Pattern"

__...___

The 2nd step is to install Newman using the "npm" task. Change the "Command" to "Custom" and the "Command and arguments" to:

install -g newman

The 3rd task is "Command line".

newman run "$(Build.SourcesDirectory)\Contact API\CE Connector.postman_collection.json" -e "$(Build.SourcesDirectory)\Contact API\Contact API.postman_environment.json" -g "$(Build.SourcesDirectory)\workspace.postman_globals.json" -x -r junit --reporter-junit-export "$(build.artifactstagingdirectory)\Results\Contact API.xml" --insecure

This is Newman running your tests from the CLI. The first parameter is the test export JSON, the -e parameter is the environment variable export JSON, and the -g  parameter is the global variable export JSON.

-x finishes the test suite even in the event of an exception, and we use junit to define the results file.

The 4th step is "Publish Test Results". Change the "Test result format" to JUnit, the "Test results files" pattern to **/*.xml and the "Search folder" to $(build.artifactstagingdirectory).

That's it! Change the pipline triggers to whatever schedule you want, and each run will publish the results in the run. Of course, you probably want some reporting on these so you don't have to go hunting down the release each time it runs, so we'll add a 5th step - "Email Report". Set whatever recipients and options you want in here, with the "Email Subject" of:

[{environmentStatus}] {passPercentage} tests passed for Contact API on build $(Build.BuildNumber)

environmentStatus and passPercentage are built-in properties of the task.

Here's the YAML for the whole pipleline described above.

pool:
  name: On Premise
  demands: npm

steps:
- task: qetza.replacetokens.replacetokens-task.replacetokens@5
  displayName: 'Inject variables'
  inputs:
    targetFiles: |
     **/*_environment.json
     **/*_globals.json
    tokenPattern: rm

- task: Npm@1
  displayName: 'Install Newman'
  inputs:
    command: custom
    verbose: false
    customCommand: 'install -g newman'

- script: 'newman run "$(Build.SourcesDirectory)\Contact API Production.postman_collection.json" -e "$(Build.SourcesDirectory)\Contact API Production.postman_environment.json" -g "$(Build.SourcesDirectory)\workspace.postman_globals.json" -x -r junit --reporter-junit-export "$(build.artifactstagingdirectory)\Results\Results.xml" --insecure'
  displayName: 'Run Contact API Production tests'

- task: PublishTestResults@2
  displayName: 'Publish test results'
  inputs:
    testResultsFiles: '**/*.xml'
    searchFolder: '$(build.artifactstagingdirectory)'

- task: epsteam.EmailReportExtension.EmailReport.EmailReport@1
  displayName: 'Send Email Report Always'
  inputs:
    subject: '[{environmentStatus}] {passPercentage} tests passed for "Contact API Production" on build $(Build.BuildNumber)'
    toAddress: '$(ReportRecipients)'
    ccAddress: '$(ReportCcRecipients)'
    defaultDomain: mydomain.co.uk
    maxTestFailuresToShow: 1000
    smtpConnectionEndpoint: 'SMTP Connection'

I wanted to simplify the naming of a large suite of Postman tests as much as possible and the following is the approach I took.

It is possible, as well as running tests from the request level, to run tests from the collection level, so that they run for all tests. Here's my collection-level test script:

const method = pm.request.url.path.join("/").replace(/^api\//, "");
pm.environment.set("currentMethod", method);

pm.test(`${method} - Status code is 200`, () => {
  pm.response.to.have.status(200);
});

pm.test(`${method} - Response time below 500ms`, () => {
  pm.expect(pm.response.responseTime).to.be.below(500);
});

The first line is building the first part of the test title for me - the endpoint that is being tested. For example, if the endpoint is:

https://someapi.domain.com/api/contacts/v1/getcontact?id=1

Then the "method" constant will be:

contacts/v1/getcontact

I'm using a regex to remove the api prefix from my test name.

The next line then injects that into the current environment variables. We'll need it later.

Then there's a couple of tests that I want to run for every endpoint in the collection, the HTTP status code and response time. They use string interpolation to inject the current endpoint in before the rest of the test title.

All that's left to do now is retrieve that method title within each individual endpoint tests to use it in the same way:

var method = pm.environment.get("currentMethod");

var contact = pm.response.json();

pm.test(`${method} - Name valid`, () => {
    pm.expect(contact).to.have.property("name");
});

pm.test(`${method} - ID valid`, () => {
    pm.expect(contact.id).to.be.greaterThan(0);
});

And there you have it. Add a similar set of tests for a different endpoint, run this suite and you'd see:

PASS contacts/v1/getcontact - Status code is 200
PASS contacts/v1/getcontact - Response time below 500ms
PASS contacts/v1/getcontact - Name valid
PASS contacts/v1/getcontact - ID valid
PASS contacts/v1/getaddress - Status code is 200
PASS contacts/v1/getaddress - Response time below 500ms
PASS contacts/v1/getaddress - Name valid
PASS contacts/v1/getaddress - ID valid

Create multiple folders under the collection for each endpoint, and they'll all be correctly labelled within the test results, no matter what the endpoint is.

Happy testing!