This is one issue that irritates me every time when I try to do node js setup for webdriverIO automation project in my mac. This issue comes when you try to do npm install in your command prompt for installing the node packages specified in your package.json. 

npm ERR! code ELIFECYCLE

npm ERR! errno 1

npm ERR! fibers@3.1.1 install: `node build.js || nodejs build.js`

npm ERR! Exit status 1

npm ERR!

npm ERR! Failed at the fibers@3.1.1 install script.

npm ERR! This is probably not a problem with npm. There is likely additional logging output above.    

npm ERR! A complete log of this run can be found in:

npm ERR!     C:\Users\deepak\AppData\Roaming\npm-cache\_logs\2019-05-07T10_36_05_651Z-debug.log

or 

> fibers@1.0.1 install /usr/local/lib/node_modules/fibers

> node ./build.js

gyp ERR! build error 

gyp ERR! stack Error: not found: make

gyp ERR! stack     at F    (/usr/local/lib/node_modules/npm/node_modules/which/which.js:43:28)

gyp ERR! stack     at E    (/usr/local/lib/node_modules/npm/node_modules/which/which.js:46:29)

gyp ERR! stack     at /usr/local/lib/node_modules/npm/node_modules/which/which.js:57:16

gyp ERR! stack     at Object.oncomplete (fs.js:107:15)

gyp ERR! System Darwin 12.5.0

gyp ERR! command "node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-             

gyp.js" "rebuild"

gyp ERR! cwd /usr/local/lib/node_modules/fibers

gyp ERR! node -v v0.10.29

gyp ERR! node-gyp -v v0.13.1

gyp ERR! not ok 

Build failed

npm ERR! fibers@1.0.1 install: `node ./build.js`

npm ERR! Exit status 1

npm ERR! 

npm ERR! Failed at the fibers@1.0.1 install script.

npm ERR! This is most likely a problem with the fibers package,

npm ERR! not with npm itself.

npm ERR! Tell the author that this fails on your system:

npm ERR!     node ./build.js

npm ERR! You can get their info via:

npm ERR!     npm owner ls fibers

npm ERR! There is likely additional logging output above.

npm ERR! System Darwin 12.5.0

npm ERR! command "/usr/local/bin/node" "/usr/local/bin/npm" "install" "fibers@1.0.1" "-g"

npm ERR! cwd /Users/mac/Documents/node/node-fibers

npm ERR! node -v v0.10.29

npm ERR! npm -v 1.4.14

npm ERR! code ELIFECYCLE

npm ERR!  

npm ERR! Additional logging details can be found in:

npm ERR!     /Users/mac/Documents/node/node-fibers/npm-debug.log

npm ERR! not ok code 0

To fix this issue, you need to check, which node version, you are running in your machine.

You can check it by doing:

node -v

In my case, it was showing some 12 versions of the node.

I googled and found that it was working with the node 11 version.

So, I try to keep both versions in my machine as some of my local projects were using node 12.

To do this, I used nvm. nvm helps you to keep different node packages and allow you to switch between them.

To install nvm in mac, you need to run this command in your terminal:

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.0/install.sh | bash

Check installed nvm version by:

nvm --version

Now install node 11 

nvm install 11.14.0

and use it in your project:

nvm use 11.14.0 

After this, run:

 npm install 

Now, it will install without giving any error.

 There are times when we observe that, we are receiving 500 or 400 responses or any other response which was not expected one from our API endpoint.  At that time, we try to hit that API multiple times, and sometimes, do not get that response. Because on re-run, it returns 200 or the desired response. 

To find out the actual root cause, we need to replicate this scenario. For replication, we will have to at least hit this endpoint more than 10, 20 times. At that time, if we will have some automation script which we can utilize to do this activity, becomes very handy.

In one of my projects, We were using Karate for API automation. In Karate, there is a very nice feature of polling (retry-until) for such Use cases. 

To use this feature, we need to first set up the retry configuration as per our need:

* configure retry = { count: 5, interval: 5000 }

So with this configuration, we can hit the request 5 times with an interval of 5 sec.

Now we need to put the condition:

And retry until responseStatus == 500

That's It.

So, with this configuration, the API will be hit maximum 5 times, within an interval of 5 seconds.

If we get the response in 2nd attempt, it will not run further.

A complete scenario is here:

Feature: Test Retry Feature

  Background:

        Given url baseURL

        * configure retry = { count: 5, interval: 5000 }

  Scenario: Fetch all Employees

         Given path 'posts'

         And retry until responseStatus == 500

        When method GET

I liked this feature as sometimes, we just want to hit the endpoint until it gives some different response than expected. Moreover, if your setup is ready then it is very easy to use.

 "I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object-oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years."

—Sir Tony Hoare (Known for Quicksort, Quickselect, Hoare logic, Null reference, Communicating Sequential Processes, Structured programming) Speaking at a software conference called QCon LondonAfter reading the statement from Sir Tony Hoare, You can understand the importance of null pointer reference. If you are a Java programmer, you probably know that It is one of the worst nightmares for us. It is a source of the myriad problems. In the series of my blog with Java8 and Automation, today, I will show the use of class Optional introduced in Java8 and how we used it in our automation script. We have some scenarios in our automation script, where we are creating one folder in the beginning and using the Folder key in the rest of our test cases to avoid creating multiple Folders.

Below is the code for that:

capturing the folder key from the already created folder

String folderKey =repositoryMap.get(RepositoryParameterEnum.FOLDERKEY.getValue());

The problem with this code is that, if there is no folder created, it was returning Null value. 

Which I was handling the script with below logic:

if (folderKey.equals(null)) {

 String folderName = "AutoFolder_" + Utils.getUniqueId();

BaseScript.createFolderServiceMethod(folderName);

}

folderKey = repositoryMap.get(RepositoryParameterEnum.FOLDERDKEY.getValue());

So this is one area where I found I can use Java8 optional class and revamp this code with better null pointer handling.

Optional Class in Java8: The concept of Optional is not new and other programming languages have similar constructs. For example - Scala has Optional[T], Haskell has Maybe type. So if you are familiar with these languages, you can correlate it. For rest, who are neophyte for this concept, let's understand it with a simple explanation:

Optional is a container type for a value that may be absent. I know, I know, you don’t like theory, so let's get into the code. So in our previous example, the folder key is the value, which sometimes holds a value and sometimes returns null. So I put it in optional, keeping in mind that the output may be null or maybe not.

String folderKey =repositoryMap.get(RepositoryParameterEnum.FOLDERKEY.getValue());

Optional<String> opt = Optional.ofNullable(folderKey);

Now, with optional I have many methods, which will help me to play this folder key value without much thinking about the null pointer. I used isPresent() method. isPresent() method returns true if the Optional contains a non-null value, otherwise, it returns false.

So, I changed my code:

if(opt.isPresent()) //returns true or will execute if the folderKey contains a non-null value

{

  FrameworkLogger.logStep("Folder key is " +folderKey);

  }

  else {

  String folderName = "AutoFolder_" + Utils.getUniqueId();

  FrameworkLogger.logStep("Create a new Folder");

 BaseScript.createFolderServiceMethod(folderName);;

  folderKey = repositoryMap.get(RepositoryParameterEnum.FOLDERDKEY.getValue());

  FrameworkLogger.logStep("Newly created Folder key is " +folderKey);

}

The code is more readable and handles the null value in a better way. So this is how, I implemented, another beautiful Java8 feature in our automation script. You can find a plethora of information about the Optional class on the Internet, so I am avoiding the part of creating the optional class and its methods. I hope, now when you handle, null value, you will use optional class and avoid the embarrassment of NullPointerException.