a coding nagger's blog

My name is Jean-Dominique Nguele and this is my blog. FLVCTVAT NEC MERGITVR

Tag Archives: javascript


Serverless’ latest release breaking Babel polyfill?

Reading Time: 4 minutes

Here, get some context

Hey everyone, let me tell you about Serverless‘ latest release. You must be thinking “Three posts in ten days after three months absence what got into you JD?”. Nothing particular, well now that I go exercise in the morning and finish work around 5 I have tons of time to do stuff afterwards. Also I keep running into things from that feel blog worty. Indeed, today I experienced what can easily become a nightmare for developers. Broken continuous integration from out of nowhere. Indeed, this morning as I was making the latest adjustments to a project set to move towards production in a few days, the continuous integration broke after merging my latest pull request. The pull request contained minor changes in a configuration but nothing that would be used at any point  through CI.

Let me add some context about the stack here, the project relies on the Serverless framework which allows building serverless solutions. By serverless solutions I mean stuff running on what you would call Functions apps on Azure or Lambdas on AWS. Pretty clever stuff that reduces the pain of setting up deployment and privileges focus on development.

Now the continuous integration part, I use that serverless package command that permits to build the package generated by the serverless deploy command that allows deploying your functions to whichever provider you want. That way after the unit tests are passed I can validate that the configuration for deployment is all set. This is the part of the CI that broke with some random error about babel-polyfill requiring a single instance.

Columboing around

This is where my biggest head-scratcher in a few months started. Continuous integration breaks after changing a configuration file used at runtime by a serverless function but not used at any point through the build steps. I could not reproduce the issue locally no matter how hard nor often I tried. Believe me I tried harder and a Gold V in League of Legends. I tried deleting the package-lock.json & node_modules then running serverless package on my local but still nothing. Still stuck. Then I checked again the file changes between the last successful CI build and the first failed one. Still nothing.

I thought that maybe it was just some timing error as it happened to me a while ago on VSTS when there was that cloudfront thing with NPM not retrieving packages. So I triggered the CI build manually but still nothing. At that point I was grasping at straws. Even compared the builds to try and figure what was the difference in execution but still nothing.

After a couple of hours I eventually went for lunch with my girlfriend and a friend of hers, still with that issue in mind. As they do when together they were speaking italian which allowed me to think through everything again but far from the screen and temptation to google things I knew would have no answer. Then I got what I thought was my aha moment. What if serverless was the reason the CI broke? Unlikely, yet I had seen way worse in the past. After all all the continuous integration was set to use Serverless’ latest release. It just kept growing on my mind while munching on that sweet chili chicken from Wasabi. It reached the point where I rushed the end of the lunch then went back to the office to check my theory.

Serverless’ latest release

The first thing I wanted to validate was updating my local to use Serverless’ latest release (1.28.0) which matched the last few failed builds. Yes few builds, as I was saying I did try loads of stuff. After the update I ran the serverless package command and it still worked. There goes my aha moment. At that point it crossed my mind that it could be my continuous integration system that could have had a weird temporary issue so I tried my luck one more time. However, this time I did explicitely set my CI definition to install the previous version (1.27.3) of Serverless just in case. I trigerred yet another build and went to grab a coffee, as one does.

You probably guessed it, I came back to another failed build. It starts to get on my nerve a bit so I decided to up the ante. I put my headset on with some some gangsta rap to go all out on this issue. So I eventually went through the logs comparing every single command, displayed verbose from the last successful build with the last failed one. I even went to check Serverless’ latest release page. I even went to checkout Serverless’ npm page. As “King’s Dead” from Kendrick started hitting my hears I got a aha moment from my previous aha moment. Do you know what happened this morning? Serverless 1.28.0 got released. Right after that I noticed something else. The last failed build still installed serverless 1.28.0 instead of 1.27.3.

Serverless' latest release

Yup, exactly

As it turns out I changed the title of the task and not the actual command. That’s what happens when you do changes pre-coffee.

Roll credits

After correcting it on the continuous build for our development environment, I triggered the build again. It worked! But I was way too happy to have figured that out to care about my previous fix attempt to have been defeated by a dumb mistake. Afterwards, I updated all the build and release definitions using serverless to explicitely target the 1.27.3 version. I guess that was a good refresher that when you setup continuous integration/delivery you should fix the versions of everything you use in your build. You can never know when people behind the tool you rely on will issue a broken release.

HttpResponseSimulator: A simple tool born over an afternoon

Reading Time: 2 minutes

What is the HttpResponseSimulator? Apart from being the least original name. Well, it is tool that allows simulating the behaviour you want from an endpoint to test an http client and/or wrapper. I built it over an afternoon so that I could write a timeout test for an http client wrapper. I had to get familiar with Node.js and Express again, which I previously used to create HappyPostman. Despite the slow start, it took me about a couple of hours to implement and deploy.

Like every small projects written with a simplistic goal the first version was not great. If you follow that link you will notice a lot of coupling and no tests whatsoever. The first couple of commits are still good enough to deploy and serve the HttpResponseSimulator original purpose. However, I wanted to push it further and live up to my whole being “future-proof” thing and make it robust. To make it robust I need it to be testable and cover as much logic as possible. This is where I started googling to figure how I to write tests and get coverage feedback with Node.js.

Due to the high coupling of my code my only option was to write http assertions related tests. The kind of tests where I hit the endpoints directly and validate the output based on the given input. In order to write these tests, I had two options that would later allow me to refactor that code to clean it up. The easy option was to follow my own tutorial on Postman and remain in a known territory.

However, I chose to try something new and stumbled into supertest that can implemented in tests that can be ran using Mocha. It seemed like the best option since I can write all my other tests post-decoupling using that Mocha too. Also, Mocha can be used along tools like Istanbul to generate coverage metrics that can be uploaded to coveralls. In that case, my choices were all driven by what I wanted to achieve which is very important in software development. Eventually after a few days of test writing and refactoring, I was finally happy with myself you can see the test coverage result below:

HttpResponseSimulator coverage results

Now that it is robust, I feel like it is time to share it with the world. It is time to make it open-source, it may just die out in a few months or grow and become something bigger. It currently serves a few more purposes than just waiting a few seconds before responding. You can now get your response from any freely available url or pastebin id among other things. If you have any improvement suggestions feel free to hit me up through Github. Actually while you’re at it, if you have any coding notion and want to try your hand at open-source development you can fork the project and open pull requests to improve it. Also, if you have a better name than HttpResponseSimulator you can google around to hit me up.

 

 

Postman collections: Making API testing great again!

Reading Time: 8 minutes

Turning shaky code into future-proof software

Over the past years we moved more and more towards web-oriented architectures, connecting to services in order to provide information. Along with the evolution of testing tools and development methodologies we can build crazily robust software. However it happens that sometimes we will not build unit tests because of project constraints. Those reasons often go from time pressure on a project to laziness but I am not here to judge.

Still, when you build a web service there is a way to ensure it works properly after implementation without doing a huge refactoring. I do not endorse not build unit tests and consider myself an herald of test driven development. That being said I am here to offer a solution for those who wrote code far from the 100% test coverage. This solution is to build API tests which is extremely easy using Postman. At least once your API tests are built you can then refactor bit by bit your code so that unit tests can be added at a later stage.

Now you can see this post as the first one of my future-proof series where I will introduce you to Postman collections and how to build flexible tests with them.

Requirements

This document has been written assuming that you have a basic knowledge of Javascript, JSON and web requests. If you do not, please feel free to visit these to be up-to-date:

Using postman makes it way easier and pleasant. Download it if it’s not done yet and you can follow through some examples later.

Creating a scenario

Create a request

Let’s start with something simple, create a new tab on Postman. Then in the textfield containing the placeholder Enter request URL type “http://echo.jsontest.com/ping/pong“. When it’s done press “Send” and you should get something like the next screenshot.

Save your request in a new collection

Now that your request is created you can save it by pressing “Save” and postman will ask you if you want to create a new collection, enter the collection details and press “Save”. Sounds repetitive but it’s the proof that they remain consistent in terms of UX.

Congratulation you just created your first Postman collection! If it is not your first then you just wasted 5 minutes of your life that you will never get back and even more by reading this whole sentence. And if you did it properly you should see this in your “Collections” tab:

Before moving into the whole Collection Runner thing we will add a test in the first request and create a second request using the response of the first one.

Adding tests

So now you will click on the “Tests” tab and you can see on the right that there is some tests snippets to help you writing tests faster. Let’s select two of them “Status Code: Code is 200” and “Response body: JSON value check”. You should now see this:

As you may notice, Postman tests are simple Javascript with some utility methods and variables that allow you to write simple yet powerful tests. This enables you to write very complex tests verifying every bit of your response. Then you can add tests around the response time, the response code the type your receive, etc.

The status code test does not need to change as the expected response code is 200 here. You need to replace “Your test name” with “Test ping value is pong”, and jsonData.value === 100 with jsonData.ping === "pong" now you should get this:

Now press “Save”, then “Send” and if you followed everything properly you should see the following:

Now you see you got the same response, and you can see “Tests (2/2)” which means that both tests passed. If you click on the Tests tab you will see the labels of the passed tests “Status code is 200” and “Test ping value is pong”:

Congratulations, you ran your first tests on Postman. If not, you wasted again some time of your life, yes it’s truly gone.

Adding a global variable for later use.

Now let’s add another request in our collection, but first we will set a global variable from the Ping pong request. Let’s go back to the “Tests” tab of the Ping pong request. In the snippets list on the right select “Set a global variable”.

From there you need to replace “variable_key” with “pingValue” and “variable_value” with jsonData.ping. Now if you press “Send” again the request is sent and the global variable is saved, click on the eye button to see it.

You can see the variable was set so now let’s move on to create the request we will use it in.

Duplicating a request and using global variables

Duplication is quite easy, all you have to do is go in your collection tab, click on the 3-dot button next to your Ping pong request and select duplicate.

Then you can rename your duplicated method “Ting pong”.

Now click on your “Ting pong” to see it in the builder, you can update the url from “http://echo.jsontest.com/ping/pong” to “http://echo.jsontest.com/ping/{{pingValue}}”. Putting pingValue between those brackets allows you to access any global or environment variable. It works as long as you try to access these values from request url, headers or body. To access a global variable from the pre-request script or the tests you use globals.variable_name. Here we will also update the test to retrieve pingValue, to do so you will replace “pong” with globals.pingValue.

Now if you run your request again all tests will pass again.

Now if you clear your globals, and try to run again the test for ping value will fail since it will send the string literal “%7B%7BpingValue%7D%7D”. This happened because you did not set any global or environment variable this time. So it will try to compare that with a variable that doesn’t exist which results in the test failing as you can see below.

However if you run again your Ping pong request, it will set the pingValue global variable therefore when you run the Ting pong request again, your test will pass again until you clear the variables.

The collection runner, finally

Now it is almost time to play with the collection runner. But first you need to know that the collections run requests based off request title alphabetic order so to ensure they run in the order you prefer I strongly advise you to use numbers for the ordering as below:

Yes you did not need this here since alphabet always places Ping pong before Ting pong. Same goes for collection folders on which I will not expand as they are really straightforward to use. If you want to have multiple scenarios in your collection that should not rely on each other you would be wise to group your requests in folders. Not only because it is much cleaner but also they can be ran individually if needed. On a 2 request collection it will not be an issue but the last one I created has 49 with 100s tests.

So now let’s go have a look at that collection runner, on your collection press on the arrow.

You will then see this, obviously the option you will select is “Run”.

The collection runner will then open after a couple seconds. You can simply press “Start Run”:

After the run you will see your collection run results.

Congratulations now you know how to write test scenarios using Postman.

Creating a new environment

Environments are pretty useful to write collections faster by using variables at any level. It can go from urls to tests values and so on. Using multiple environment is frequent for complex systems with multiple deployments and/or gateways.

Now we will create a simple environment  and set the ping service url that we will use in both requests.

First of all, click on the gear icon then “Manage environments” > “Add”. Once you get there you can name your environment and setup the values you need. 

Here we will name it “Postman tutorial environment” and add a key pongServiceUrl set to the value “http://echo.jsontest.com/” then press “Add”.

 

Now you created your environment you need to select it from the dropdown.

Once it’s done you can then update the urls from both your requests to use {{pongServiceUrl}} like this:


Now if you go to the runner again the environment is already set. You can press “Start Run” again.

Now you will see the same results as previously but with updated urls.

Congratulations! You now have all the tools you need to write fully flexible test collections. Your creativity is your only limit.

P.S. Today I turned 26. No I did not write this post on my birthday but did corrections and added screenshots today. Happy birthday to me!