Forem: Millan

Run your first RESTful API / service using docker

Millan — Sun, 06 Feb 2022 08:14:50 +0000

Liquid syntax error: Unknown tag 'endraw'

5 misconceptions regarding test automation

Millan — Wed, 22 Sep 2021 13:55:57 +0000

These are the top five things you should remember about software testing and quality assurance when it comes to test automation.

A super quick background

I used to think that test automation is a some magical capability and 100% automation meant :

No more Bugs !

No more checks !!

No more manual Testing !!!

Very soon did I realised, not only that I was mistaken but also wrong to a larger extent….

Why ?

Flash-back: A decade ago somewhere around 2011. When software used to be released annually also called as waterfall model. ( in some companies it still exists, depending on the nature of project such as long term Gov projects ).

I was a junior test engineer back then. And I always thought that one day I will get the chance, a golden chance to learn testing tools with hands on. And to change the world of software testing.

Which meant: testing with tool that costs to the company. And only handful of senior engineers used to do test automation ( HP QTP) or performance testing (Load Runner).

Well I did it. I mean not change the world kind of thing but in next few years I got hands on with :

1\. Web using selenium Java

2\. Mobile using Appium

3\. REST API with Hibernate, newman in CI..

4\. Performance testing with LR/K6

and many more….

It was exciting and I really enjoyed the learning phase ( I still do...)

But with my experience I realised many things that I understood early were proving me wrong.

With that said here are the top “5 misconceptions on test automation”

1. Automation can replace 100% manual testing

Handful of companies can run test automation in production. Few due to limitation of test data and some due to legal and compliance . So you usually do testing manually.

For example if you are a part of banking project, you login to bank account ( web/app ) using your own account.

# Do you run automation in such cases ? NO

2. Automation Testing is a rare and hard skill.

..the average adult human brain has the ability to store the equivalent of 2.5 million gigabytes digital memory. Reference this article

While that is a Hard-disk comparison. If we talk about memorising power or computing, its much higher. At least much higher than test automation currently available. AI + Test automation would be an interesting future article.

I guess that argument is enough to cover the fact.

# Automation Testing is a rare and hard skill. ? NO

3. Automation makes your job easy ..easily

May be yes only when it comes to re-testing. Regression testing.

But NO when:

We are building test automation framework itself
We are maintaining test frameworks
When test environments are not stable
When test data is a root issue.
When your projects needs more exploratory testing of new features.

So,

# Automation makes your job easy ..easily ? NO

4. More automation means less bugs

This is a big one !

Usually such misconceptions surfaces from management expectation. Where everything is celebrated on percentage (%) of coverage rather than quality of coverage.

While having more and more automation is not a bad idea, But what if we have 100% automation and that covers zero (0) negative scenarios.

Once again unscripted testing such as exploratory testing is a best tool. With that you have the independence to test fast and get results on negative scenarios.

# More automation means less bugs NO

5. Manual testing is a dead skill, Test automation holds the future

This will never happen and ideally this should not happen.

Over the time test first approach such as #TDD ( Test driven development) approach where:

You decide on a test ( business scenario)
Write a test first , which fails right away
Then you write development code to achieve it and mark as PASS
Again you pick another test and develop..

Another great example is #accessibility testing of web and mobile apps.

Successful teams maintain the balance of trusted manual testers and automation testers. But remember manual testing has its own charm and why not , its a critical thinking skill.

# Manual testing is a dead skill, Test automation holds the future ? NO

Key takeaway :

Automation is a compliment to manual testing not a substitution !

Image credit: Zan | Originally posted on medium in Sep 2021

Running a local server and API testing in less than 10 mins 😮

Millan — Sat, 18 Sep 2021 04:57:48 +0000

Time is money 💲

So in next 10 minutes or less 🤞 I promise, we will:

Start an API server on your machine (localhost)
Run independent API test on ☝️ server.
- Test's include assertion

✔️ All this without using any dependency !!! ✔



+                      Time starts now ⏱️

Fig.1 - 10 minute timer

Step 1 : Set up the node / NodeJS

💡 Think of NodeJs like JVM if you are familiar with java

If you already have it setup then you can jump to Code and run

Go to nodejs.org and download / install NodeJs on your platform. You may also Check their official Releases page

macos users : brew install node
linux users : sudo apt install node

Check installation by running this node -v on your terminal / cmd and you will see :



node -v
v16.8.0

Version 16 was the latest while writing this article.

☑️ And that's all you need today in terms of setup

Run and Test in 4 simple steps

1️⃣ Setup server ✔️
2️⃣ Run server 🏃🎽
3️⃣ Write tests 📝
4️⃣ Run API test's 🚀

To keep it simple, we will keep server and test files in the same folder/directory.

So lets create a folder named dev on Desktop



Desktop/dev

Let's Start 👉 !

1️⃣ Setup server✔️

Go to dev folder (cd Desktop/dev) and create a file named server.js and copy this code:



//server.js

const http = require("http");

const HOST = "localhost";
const PORT = 8020;

const server = http.createServer(async (req, res) => {
console.log("Request on server received :  " + req.method + " : " + req.url);

  /**
   * Health check endpoint `/health`
   * 
   * @path {HOST}:{PORT}/health
   * @return status : {200}
   * @return message : text : "If you see this message, your API server is all set , Welcome !"
   */
  if (req.url === "/" && req.method === "GET") {
    // set the status code, and content-type
    res.writeHead(200, { "Content-Type": "application/json" });
    // send the response data as text
    res.end("If you see this message, your API server is all set , Welcome !");
  } 


  /**
   * Health check endpoint `/health`
   * 
   * @path {HOST}:{PORT}/health
   * @return status {200:OK}
   * @return uptime : how long has been server up & running
   * @return timestamp : Time of response from server  
   */
  else if (req.url === "/health" && req.method === "GET") {
    const healthcheck = {
      uptime: process.uptime(),
      message: "OK",
      timestamp: Date.now(),
    };
    res.end(JSON.stringify(healthcheck));
  } 


  /**
   * Endpoint not implemented / invalid endpoint
   * @path {optional} `/`
   * @return {404} - Route is not implemented (Page Not Found)
   */
  else {
    res.writeHead(404, { "Content-Type": "application/json" });
    res.end(
      JSON.stringify({ message: "Route is not implemented" })
    );
  }
});

server.listen(PORT, () => {
  console.log(`server started on : ${HOST}  port: ${PORT}`);
});

So we ☝️ we created a server which will run (in next step) on . We have created these 2 endpoints:



http://localhost:8020/        //Base url : GET Home Page
http://localhost:8020/health  //Health   : GET server status

Next 👉 !

2️⃣ Run server🏃🎽

Open your terminal/cmd and navigate to Desktop/dev



cd ~/Desktop/dev

and run your server using this command:



node server.js

If you see this message, it means your API Server is all set !

Fig.2 - server started on http://localhost:8020

You can even check it on your browser:

Fig2.1 - server ( http://localhost:8020) accessible on browser

Next 👉 !

3️⃣ Write tests 📝

Under same folder Desktop/dev now create a file named test.js and copy this code:



//test.js

const http = require('http');
const assert  = require("assert");

let BASE_URL = "http://localhost:8020";


  /**
   * Test 1 : Hit BASE_URL and assert response statusCode to be  === 200
   * 
   * @path {BASE_URL}
   * @return expect : {200}
   */
http.get(BASE_URL, (response) => {
      console.log("Response: " + response.statusCode);
      assert(response.statusCode === 200);
    });

  /**
   * Test 2 : Hit `/health` endpoint and assert response statusCode to be  === 200
   * 
   * @path {BASE_URL}/health
   * @return status : {200}
   */
http.get(BASE_URL+'/health', (response) => {
      console.log("Response: " + response.statusCode);
      assert(response.statusCode === 200);
    });


  /**
   * Test 3 : Hit random endpoint `/thisIsNotAValidEndpoint` and assert response statusCode to be  === 404
   * 
   * @path {BASE_URL}/thisIsNotAValidEndpoint
   * @return status : {404}
   */
http.get(BASE_URL+'/thisIsNotAValidEndpoint', (response) => {
      console.log("Response: " + response.statusCode);
      assert(response.statusCode === 200);
    });

Next 👉 !

4️⃣ Run API test's 🚀

‼️ Make sure you open a new terminal/cmd window to run this and also be sure that our server is still running (step 2️⃣ Run server🏃🎽 ) on separate terminal/cmd.



node test.js

you will see something like this



dev $ node test.js 
Response: 200
Response: 200
Response: 404
node:assert:400
    throw err;
    ^

AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:

  assert(response.statusCode === 200)

    at ClientRequest.<anonymous> (.../Desktop/dev/test.js:40:7)
    at Object.onceWrapper (node:events:514:26)
    at ClientRequest.emit (node:events:394:28)
    at HTTPParser.parserOnIncomingClient [as onIncoming] (node:_http_client:621:27)
    at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)
    at Socket.socketOnData (node:_http_client:487:22)
    at Socket.emit (node:events:394:28)
    at addChunk (node:internal/streams/readable:315:12)
    at readableAddChunk (node:internal/streams/readable:289:9)
    at Socket.Readable.push (node:internal/streams/readable:228:10) {
  generatedMessage: true,
  code: 'ERR_ASSERTION',
  actual: false,
  expected: true,
  operator: '=='
}

WHAT❗

What just happened ❗ , why all these logs are printed.

😄 Well it is expected, here is why ⬇️

In the above test.js this was intentionally put to demo, what will happen when an test fails on assertion.

Troubleshooting : Start by reading error printed:



AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:

  assert(response.statusCode === 200)

It is trying to tell you that, the expected response code 200 was not received.

Que: But which one ??

Answer : Read just 1 more line from logs it tells you exactly where test.js:40:7



 at ClientRequest.<anonymous> (.../Desktop/dev/test.js:40:7)

Let's Fix this :

Open test.js in your text editor.
Go to line # 40



assert(response.statusCode === 200);

Change 200 to 404



assert(response.statusCode === 404);

now save and close this file.

Self assignment: Try to explore the reason yourself.
hint: line # 33 of test.js

Let's try to run test's once again 🏃 🚀



node test.js

Done !

Fig.3 - Successful Test run ✔️

Fig.3.1 - Time over

Hope you enjoyed my first article on dev.to 🎉

Credis: API icon by Icons8