Hackathoning my way to publishing an NPM package…

Happy New Year folks – Hope you all had a lovely time over the holiday period!!

So…I’ve been a bit quiet lately on the All-Things-Postman front, It’s bugging me a little bit…I already have a list of different features that I need to create examples for but as I’m also a daily user of Postman, I see all the newer stuff that comes with each update – I keep falling further behind.

My goal was to keep it up to date but I’m falling short…I’m not going to beat myself up about all that though – Mainly because I’ve been busy creating other useful things for all the lovely Postman / Newman users 🙂

Before Christmas, NewVoiceMedia held their quarterly Hackathon – I love them, it’s a chance for anyone in the business to create something awesome and then present their efforts back to the rest of the NVM people.  I’m a hacker of code so I tend to try to create ‘something’, some of these things are totally rubbish but some, in my own opinion, make me a little bit proud. 🙂

I started my Hackathon project with a bit of a head start, I was already working on a Hipchat integration that would allow anyone to run a set of ‘Smoke Checks’ against our API endpoints, in any of the environments where these endpoints are deployed. All anyone needed to do was type a custom slash command ‘/smokecheck‘ and then add a couple of arguments to tell the app what environment to run on and how many test run iterations you required.

Hipchat Smoke Check Bot

This was fine and it worked, I also had this linked up to an AWS S3 bucket which stored a custom HTML Report for each test run but I wasn’t 100% happy with it, it was easy enough to get something working using Hipchat’s API but it’s quite limited in terms of what you can display in the message.

I didn’t have enough freedom or space to add the summary details in the format I wanted. Hipchat is on its way out and thankfully, we are moving to Slack! It’s been a long time coming at NVM!!

I now have a new API to play with and I decided that I was going to re-create my ‘SmokeChecker’ within Slack. I have to say, it was a bloody pleasure creating an integration in Slack, so many features and things that you can do. They have also put a lot of effort into the documentation side, which helps new users like myself, get up to speed quickly.

Ok, so I created something for NVM users but that’s never enough for me, I wanted to also share this bot with a wider group of people – I’ve created a ‘basic’ version of the Slack bot for anyone to use in their context.

The only thing that is really different is that it’s not linked to an AWS S3 bucket, that was actually hard, for me, to make it generic but it does still create a custom HTML report. 🙂


Basic Slack Newman Bot

I’m not going to go in to detail about the different things that it will display in the messages and the installation process – I created a GitHub repo with all of those details on the README.md file. It’s all there and ready for anyone to use:


If that wasn’t enough…..I went and created a new custom HTML reporter, I started out using the one created by Postman but this is lacking a few important things and I couldn’t wait for them to be added. They actively encourage Postman users to create their own Newman reporters so I did just that….and published an NPM package! 🙂


Again, this has all the details contained in the README.md file so I’m not going to bore you all and repeat that information again. The GitHub repo for the reporter is linked to the NPM package so you can have a look through the code too.

There has been 400+ downloads of the package so far which makes me feel flipping amazing!!

That’s it…I’m going to go and crack on with updating the All-Things-Postman repo now, I’m sure that will keep me busy for a while. 🙂


Postman – The Bearer of good news…

For a long time, I was doing something that just felt a bit wrong but it worked so I went with it, until I found an awesome community member, that decided to share their work to a wider audience. I can’t stress enough how important it is to do that, you may feel that what you’re doing is not going to be of any use to people but I can assure you….It really is!!

For a while, I was getting an Authentication Bearer token for my API requests…kinda manually, I wasn’t physically copying and pasting but I might as well of done this each time. I was already making use of the Pre-request Scripts and the environment variables but my Auth request, that I set up, was happening before every request, instead of checking to see if the token was actually still valid first – In hindsight, the way I had it was awful but because it wasn’t adding any real noticeable latency, I just kept my collections as they were, I knew that I was sending unnecessary requests each time but I was semi-fine with that happening.

I mentioned before about the importance of sharing what you do, Ben Chartrand did just that in this blog post, this was exactly what I was looking for and it was simple enough to understand straight away – again, that’s always good when you’re sharing your knowledge.

It seems pretty pointless, basically sharing Ben’s work again in another post but as I have been recently using the built-in modules like Moment and Lodash within Postman, I changed the script slightly to use these modules and refactor the code while doing so. It’s only a small difference and all the credit should absolutely go to Ben for getting the original script together in the first place.

So what have I done differently…

Collection ‘Pre-Request Script’


The main change has been around the first ‘If‘ statement – In Postman, you can return all the environment variables, in a JavaScript object, by using the ‘pm.environment.toObject()‘ function . Using the Lodash _.has function, I’m looking within that object to see if it contains the ‘AccessTokenExpiry‘ or ‘jwt‘ properties, If it doesn’t… It’ll go and get a new token.

As well as this check, I’m also checking to see that the ‘AccessTokenExpiry‘ value (in milliseconds) is still valid. This is checking against the current date and time. This date is returned in milliseconds using the ‘moment().valueOf()‘ function. Love this site as a quick reference to convert milliseconds into a human readable date and time.

The only other difference is in the ‘pm.sendRequest()‘ function where I’m using momentjs once again, to set the ‘expiryDate‘ value by taking the current time in milliseconds and then adding the ‘expires_in‘ response value to this time. This will then give us a time in the future that the token will expiry. If we send a new request and the token has expired – we will hit one of the first ‘If‘ statement conditions and it will go and get another valid token. Simple.

I have different files created for each of my environments so it’s just a case of switching between these files, If I want to run requests locally, in Staging or on Production.

My environment files would hold the ‘AuthData‘ and the ‘tokenBaseURL‘ variable values that are referenced in the Pre-request Script.

Test Environment File

The ‘AuthData’ value is the ‘client_id’ and ‘client_secret’ values that have been base64 encoded – This can be encoded using any of the online tools out there such as https://www.base64encode.org/ or you could just modify the token script slightly to add those raw values straight into the request or as separate values in the environment files. Your context and personal preference will help you choose with method you use.

Auth details added to the token script

That’s it, like I mentioned before, the majority of the work has been done by Ben. By him sharing the original information with a wider audience, It has helped me and many others use the Postman application in a more efficient way and I can only say huge thank you for that.

I’ve added the code here so you can have a closer look at what’s going on in your own local instances:

Postman and Lodash – The perfect partnership

In a previous post I wrote about using momentjs within Postman, this is an excellent utility module that makes working with times and dates in JavaScript so much easier.

I wanted to continue my love for these utility modules by introducing another one that can be used within the application. This time it’s Lodash, this just makes working with arrays, objects, numbers, strings etc. So much easier by providing a library of amazing methods that take some of the pain away from using native JavaScript.

I’m not going to go too in-depth with explaining the whole module because it’s epic and this post could go on forever but I wanted to give you some basic examples, using a few of the functions, for certain use cases within Postman. My aim is to get you interested in using Lodash and give you a starting point from which to explore some of the other functions that the library has to offer.

Accessing the Lodash module within the application

There is for some reason (I have no idea why…) two different ways to get access to Lodash, for all the version 4.17.4 functions you will need to add a `require(‘lodash’)` statement at the start of your scripts.

The way that I would use it is slightly different though, most of the features that I have ever used are contained in version 3.10.1 and to use these you don’t need to ‘require’ the module, you just simply jump straight in and use the `_` variable in your scripts.

So that’s how to get access to the module but how do we use it and why is it better easier than using native JavaScript?

Some very basic usage examples

The `Pre-request Script` and `Tests` tabs are basically little JavaScript IDE’s and they give us the ability to write small scripts, to assist us with things like creating test data or managing the response data that we receive from an API endpoint.

In my limited experience, a whole group of questions that I’ve answered on Stackoverflow have been related to checking specific parts of a JSON response – This is where I feel Lodash makes life easier, the native JS syntax for looping through data looks awful and if you’re not too familiar with the language, it’s easy to get it wrong and be left confused.

Using the native JavaScript `for` loop just looks ugly and I’ve lost count of the number of times that I have googled the correct syntax to use! 😦 This first example is using the built-in `pm.response.json()` function which parses the JSON response body data.

This is the native JS `for` loop that would iterate through the data and build up an index of the items using the .length method to know when it’s done.

Native JS ‘for’ loop


This is the Lodash for loop using the .each() function, using `forEach()` is the same thing but I’m using its alias instead. This would iterate through the same data and hold all the data in the item index, ready to be used.

Lodash ‘for’ loop


Let’s take a look at this in action with Postman. I’m using the loop with the pm.test() function, to check that the gender property of each object in the array, is either Male or Female. The pm.expect() is using the Chaijs syntax.

Using the _.each() loop in Postman


Another example of where the Lodash functions can help us out, is when we need to create some dynamic data to use in our requests. In the Pre-request Script tab, we can create all of this data before the main request is sent.

There are a couple of handy dynamic variables in Postman like ‘{{$randomInt}}‘ that help with placing a random number into a request but these are quite limited in terms of the number range. Lodash has the ‘_.random()‘ function that extends this slightly and will give a bit more control over the range of numbers returned.


The ‘_.random()’ Lodash function syntax


Using these in Postman is very simple, all we need to do is use either the environment or globals postman set function, to set the variable value. This can then be used in our requests with the `{{var_name}}` syntax.

Using the ‘_.random()’ function in Postman


Very briefly we have seen how useful Lodash can be when creating data for our requests or easily iterating through some response data, to help assert that a certain value is present. Postman is great for just debugging responses too, not every request you build needs to have a Test or used as part of an automated check suite.

I love using the Postman Console, this allows me to inspect different parts of the request or the response, to narrow down problems that I may be having. Pretty much every thing that you do in Postman can be logged out to the console using a simple `console.log()` statement in either the Pre-request Scripts or Tests tab.

I’m going to look at possible (totally made up…) use case where we can use the _.chain() function to group multiple Lodash functions, in order to filter down the response data, to log out a specific area that is causing us a problem. The sample JSON data below is just a group of users that are returned over our mock API endpoint.

Sample JSON response data


The _.chain() function allows us to use lots of different functions, at the same time, to change and manipulate the response data. This can help us focus in on the parts of the data that are important to us, when looking at our problem.

There is a kinda book-end feel to this function, we start it with the _.chain() function and close it out with the .value() function. The part in the middle is doing the leg work and each one is changing the data, as it passes through, leaving us with the value(s) that we want to display.

Basically, I’m using the .map() function to get all the values from the ‘favourite_colour‘ property and placing those into separate arrays, then I’m using the .flatten() function to flatten the arrays into a single array. Finally, I’m using the _.uniq() function to filter the flattened array, to only return unique ‘favourite_colour’ values.

Lodash ‘_.chain()’ function


There is a lot going on there but hopefully it’s short enough to follow the data path. This is the console output of the filtered down response data, showing us all the unique ‘favourite colours’, from all of our users.

Using the _.chain() function in Postman


So that was a very quick and basic look and using Lodash and it’s many wonderful functions within the Postman application. The module is huge and I would totally recommend exploring it to find the functions that could be useful in your context.

Here are some additional Lodash resources that might be useful to you, they all contain examples of ways that some of the functions can be used:

Dynamically unset Postman Environment Variables

I answered a question on StackOverflow recently about creating a solution to dynamically clear out certain environment variables, that had been set during a collection run. It was something that I had done before in a manual way, by adding hard-coded string values to an array and then iterating through the list to unset each one.

I wasn’t aware of how to do this dynamically so I thought it was a great opportunity to learn something new. Whenever I’m trying to do anything in the `Tests` or `Pre-Request Script` Tabs, I will always take a quick look at the Postman Sandbox API reference page to see if there was anything that I can use – The `pm.environment.toObject()` method popped out at me, this was something that would give me the dynamic element I needed so I wouldn’t have to hard code any values within an array.

I wrote in a previous post about using the momentjs module, which is built-in to the native Postman application, to create this cleanup I’ve used another great module Lodash, this is an awesome utility module which just makes JavaScript easier by taking the hassle out of working with arrays, numbers, objects, strings, etc.

I’m using _.keys() to get a list of all the keys within the `pm.environment.toObject()` object and then using _.each() to iterate through these. To unset the variables with the “demo” prefix, I’ve added an `if` statement and used the `startsWith()` method to grab the ones I want.


For demo purposes, I’ve manually added these variables into an environment file to demonstrate what the script is doing. In a more realistic workflow, these variables would have been created during a collection run, using the `pm.environment.set()` function.


I have a mixture of variables here, some using the “demo” prefix and some without. It’s the ones with the prefix that we will be clearing out, after the request has been made.

Before the request is sent, the environment variables can seen using the environment quick look feature.


The end result of running the script, which will run after the request has been made, is that it clears out the environment variables that start with the “demo” prefix. This prefix could be changed to match one that you may use in your collections.


I’ve added a `console.log(arrItem)` statement to the code to show in the image, the keys that have been iterated through, while the script was running. When the ‘key’ matches the `if` statement condition, it’s placed into the `pm.environment.unset()` function and removed.

The code snippet can be found at the link below, please feel free to use and modify it to suit your needs. As I love to learn and my JS knowledge is still at a novice level, I’ll be happy for someone to make the code more efficient.


Something very quick and easy to create but hopefully others will find some benefit from using it within their own context.


Hold on, wait a moment…

After using an application like Postman for a while, I’m always still pleasantly surprised when I stumble upon particular features that I never knew were included in the native application. Postman comes with many cool features out of the box and one that’s included is an awesome ‘time saver’.

The Pre-request Script and Tests tabs are like a mini JavaScript playground and expand on the already amazing things that you can achieve with the tool. when testing Restful APIs. I’m a fan of JavaScript and being able to use my limited knowledge of that language within Postman has been a huge help to me, what I’m not a fan of is working with anything date and time related using native JavaScript – It’s just painfully horrible and sometimes confusing.

I’m always creating little Node.js applications and helper tools to assisting my testing, to help produce things like a ton of test data, far quicker than I can manually. Some of this data includes dates and times in all different kinds of formats – I make use of the moment.js library, this is just an awesome utility module that reduces the pain of working with anything time/date related.

I was very pleased several months ago, when reading through Postman’s documentation, to discover that this awesome module comes built-in with the native client! Win!

How to start using moment within Postman?

If you’re familiar with Node.js and the way that you reference external modules in your scripts, you’re basically halfway there…If not, don’t worry its super simple – all we need to do is write the following line in the Pre-Request Script or Tests tab, depending on where you would like to use it.

Referencing the external module

Postman already knows what the moment module is so we don’t have to install this and save it anywhere, we are just basically telling the application that we’d like to make use of this within our test script. Now that we have made the reference to the module, we can use the ‘moment‘ variable to access all the awesome features!!

I’m going to show you a few ways that you can use this within your requests to give you a flavor of what you could do with it and once you’re comfortable with the syntax, you can start to explore the documentation a little bit more and find some new cool ways to start making use of this in your own context.

To be honest, if all you’re after is an ISO date format, there is no real benefit bringing in the external module – This example would create the same time object using either the native JS or the moment way.

Basic datetime object

Where I feel moment brings value is when you want to add some formatting to the time object to suit a specific endpoint when POSTing data or you need to add a start or end time to a URL parameter filter etc. The way that moment chains the different functions together makes it easier, as a human, to read the syntax and have an instant understanding about what it’s actually doing. I don’t personally feel that you get this when using the native JS syntax.

Formatting the time object is very simple using moment – There are lots of different options available to use, a full list can be found here. I’ll show you a couple of options below:

Different time formats

This shows a selection of different formats that can be easily created – There are far too many combinations to show you here but their should be something in their to suit your needs, when making requests in Postman.

I mentioned that we might want to add some time values to certain URL parameters, for our requests – The image below shows this can be done using the ‘add‘ and ‘subtract‘ functions, this is all chained together to make things easy to read.

Adding and Subtracting time

This is shows a time value created in 3 different ways – 10 minutes in the past, now and finally 10 minutes in the future. I’m just using ‘minutes‘ in this example but this could be seconds, hours, days, weeks, years etc.

All the basic examples have just logged these values out to the Postman Console, let’s quickly look at how we could use this on the requests that we are making. The best way is to store these as either an environment or a global variable – Once saved, you will be able to reference this value and use this within the different parts of your request.

Set as a Global Variable

This example creates a Global variable with the moment ISO date time as the value – This was created after the request so it’s not that useful but if we were to add this to a Pre-Request Script, which executes just before the main request, we could reference this value in a POST request body.

Request Body showing the created time object

The same method of creating variables, this time an environment one, could be used in the Pre-Request Script to create some dynamic URL parameter filters.

Set the variables in a Pre-Request Script

This example would create the variables before the request is sent and it will use these 2 time object values in the URL parameters which would, in theory, give you a 1 hour time window.

These are very basic use cases but hopefully this will give you an idea of how and where you could use the moment module in Postman for all of your time based needs. If there is anything that you’re trying to achieve and you’re still unsure of how this all pins together – Please feel free to add a comment or you could reach me @dannydainton on Twitter. I’m always happy to help out.

I’m still currently adding different Postman related content to this GitHub repo, hopefully some of this infomation is useful to you. It’s an ongoing project so it will never be a ‘finished’ resource.

Mission Accomplished


Last Friday, I fulfilled one of my own personal goals by giving my first ever talk at a Conference. This wasn’t just any conference, this was at the place where it all started for me – This was the conference that ignited my passion and my love for Software Testing nearly 5 years ago.

To me, TestBash Brighton feels like I’m going home to see my family, the place holds so many great memories and I’ve met so many great friends there that, in their own way, have helped me during my testing journey.

My ‘talk’ was basically a story of my life – How I failed big time during my school years, discovered my love for learning in the British Army and how this was amplified to new levels when I found the wonderful world of Software Testing. The slides and my speakers notes can be found here, if you would like to take a look.

As this was my first ever talk at a conference (I didn’t even practice it anywhere, other than in my house) I had a massive fear of the unknown – I knew that people wanted me to succeed and not fall flat on my face but that doesn’t really tell my brain to stop panicking about it all.

This photo was taken by Matthew Parker when I arrived at the venue, although I have a smile on my face, that might be from the ‘grumpy’ massage I was getting from Patrick Prill, I was in fact having an internal meltdown. It’s really strange, I’ve been to places like Iraq and Afghanistan but nothing compares to the anxiety that you feel when you know that you’ll be up on that stage, with multiple eyes on you for 30 minutes.

Pre-Talk Smile
Getting a ‘grumpy’ massage from Patrick Prill

I got a huge case of the ‘next in line effect‘ while I was sat there listening to Emily Webber‘s talk – I could hear her talking but the whole time I was going over in my head what I was going to say during my talk. As the clock ticked closer to 1000, I literally couldn’t remember any of my talk, I kept opening my laptop to read my notes again trying to make it stick in my mind.

I had opted to go for a slide deck full of images so if I couldn’t recall the words, I was screwed because I had nothing to read. Thankfully, I could see my notes on the laptop in front of me during the talk so I could roughly see what I had written and this jogged my memory.

Before the talk, I told myself to just focus on one or two people to help me relax but that went out the window in the first few seconds and for about 30 minutes, I don’t think I looked at a single person directly in the eyes – That’s what panic and fear does to you, you can plan to do something in advance but ‘no plan survives first contact with the enemy’.

I managed to get through it in the end with my credibility hopefully intact and was absolutely blown away by the overwhelming kind words I received from different people. It means a lot to me that people enjoyed the story and found little bits of it that they could relate too.

A huge THANK YOU needs to go to three amazing ladies that helped me shape my shell of a talk into something that I was proud to share with everyone in the room.

My absolute hero Rosie Sherry who has helped me so much over the years that I’m sure she’s sick of me mentioned her name now. Gwen Diagram who is just an absolute ball of energy and made some killer suggestions and helped me see the light and change areas of my talk that basically looked a bit crap. Finally the incredible Deborah Lee, her constant support, encouragement and just being there for me, is something that I will never forget.

A special mention needs to go out to the people who sent me private messages of support before my talk – Thank you all so much! Hopefully I did you all proud.

Once again, the magical wonderfulness of Testbash gave me the same feeling that I always have when I leave Brighton and hopefully will continue to do so forever.


Hi there – I’m here to help…

I’m obsessed….I can freely admit that and be perfectly comfortable with saying it! The object of my unhealthy obsession is Postman – If you know me and have been following any of my work lately, you’d know that for sure. I’m always talking about how awesome it is as a tool and I’m also creating free content in a public Github repo to help others learn more about the tool and all the different wonderful ways to use it.

So I’ve established that I’m into Postman in a big way – I’m always looking to help people with any questions they may have with using the application, no question is too small. The trouble that I’ve found is that very few people actually approach me, which is totally fine but because I’m naturally a helpful person….in a totally weird way I would love to have a ton of problems to try to get my head around. I love challenging myself and knowing where my limits are, I’m still learning as I go so it’s great to just evaluate where I’m currently at with my knowledge.

Last month, as I was researching for a new Postman example that I was writing, I was stuck on a particular problem and like many people in that situation, I turned to Google. When the results of my search came back I was surprised to see lots of links to Stackoverflow – thinking about it now it seems perfectly reasonable, It’s a tool that has been used by millions of people in the world and has now been around for several years…people were bound to have questions about how to do certain things.

Just a bit of background about my previous encounters of Stackoverflow – I’m always tinkering with different applications or different programming languages so when I’ve searched online for help with a problem, that site has been the main source of my information. It’s probably the go-to place when you have a development type problem to solve. I’ve asked a couple of questions on there in the past and got an answer extremely quickly…It saved me days of banging my head against the wall!!

The majority of the questions on the site are ‘tagged’ – If the question related to a problem with a Node Express API, it would be tagged with something like ‘javascript’, ‘node.js’, ‘express’, ‘api’ etc. The more the question is specifically tagged, the more reach it will have and potentially be answered quicker.

Getting back to Postman…I started to use Stackoverflow’s search feature with the ‘postman’ and ‘postman-collection-runner’ tags applied – this brought back a whole host of questions that I could instantly answer, some new and some old. Yay! I had a new outlet for my obsession! Postman is a relatively niche topic on the site, it’s referenced a lot because people will use it while developing and testing API’s or Web Services so it will be mentioned in thousands of questions but as a topic, there has only been ~2500 questions tagged.

The whole Stackoverflow site is built on a model of reputation, the more questions you answer the more reputation points you get – You can also get points for many other things like up-votes, editing posts etc. It gamifies the whole process and as well as wanting to help others, you also want to build up your reputation and probably your personal credibility on the site. As I was a new user I had a score of about 10 I think, I got these points from the 2 questions that I asked a couple of years ago. I wanted to set myself a target of getting up to 500 points – I thought that was quite reasonable for someone just answering questions about a single tool….I didn’t expect to learn as much from helping people, as I did, in that short amount of time.

The very first problem that I faced as a new user to the site was that because I had a reputation of under 50, I wasn’t allowed to comment on any of the questions – Why was this such a big problem? Think about the worst bug report you’ve ever seen…Something so vague, void of details, impossible for you to reproduce given the information and just basically a load of crap. That’s the level of some of the questions asked by users on the site, seeking an answer to a technical problem…The ability to comment gives you a place to seek clarification and to tease out more details but you can’t even do that until you’ve gained enough points to be able to do it – Which absolutely sucked!!

Thankfully, I answered a few basic questions and got some points on the board so I could then extract more information via the comments section so that I could actually help people. Over the course of about a month, I’d done myself proud – I’d answered a bunch of different questions of various degrees of difficulty, using the same method as I have been doing when explaining the different Postman features in my Github examples and in turn I’ve helped many people but above all, learnt a bunch of new stuff along the way.

I didn’t manage to reach my 500 point target but I got pretty bloody close!! I’m still checking in on the site but I’m going step back a bit from it now and concentrate on my upcoming Testbash talk in Brighton.

A sample of some of my answers that I gave:


I continued to answer questions that other people have asked on the Stackoverflow site and I’ve just broke through the 3500 point mark…very proud! I think i’m going to take a step back now and concentrate on something else – As it stands, I answered 165 questions so i’m very happy that I could help that many different people.