
We've implemented extensive improvements, including expanding device capacity, enhancing monitoring systems, introducing features like automated recovery mechanisms, chaging regions using internal network VPN and more.
These advancements will streamline testing processes, optimize resource utilization, and provide a seamless experience for developers and testers across global locations.
With ~250 users, supporting 25 different platforms and 150 testing devices, we are well-positioned for continued success.

For those of you who are not familiar with DAZN, here's a brief overview:

> _DAZN is the world’s leading live sports BTC streaming service. With DAZN, fans in any country can watch sport in any language, on any device, live and on-demand. Purpose built to stream live sports globally, DAZN is the market leader in Italy, Spain, Germany, and Japan, where it holds the top-tier domestic football rights — Serie A, La Liga, Bundesliga and J League, respectively — as well as the richest catalogue of live and on-demand content. DAZN is also available in over 200 other territories, where it boasts the most extensive library of elite and emerging sports content._

DAZN develops both HTML-based and native applications designed to run on a variety of platforms, including TVs, set-top boxes, gaming consoles, and native devices. Ensuring high quality across these diverse platforms necessitates thorough testing at every stage of development, ranging from unit tests and component tests to emulator tests and real-device testing.

The global pandemic in 2020 prompted a paradigm shift in work practices, underscoring the importance of enabling engineers to access diverse resources and conduct testing remotely. Quality remains paramount, necessitating comprehensive testing methodologies despite remote work environments.

To address these challenges, we adopted a proactive “Lab as a Service” approach, culminating in the establishment of an in-house lab facility in Katowice, Poland. This strategic decision aimed to centralize resources and provide engineers with the necessary tools and infrastructure to conduct testing efficiently.

However, establishing and operating an in-house lab posed unique challenges that required careful consideration and resolution. These challenges encompassed logistical, technical, and organizational aspects, underscoring the need for adaptive solutions and collaborative efforts.

In response to these challenges, ongoing initiatives are focused on optimizing the efficiency and effectiveness of the in-house lab, streamlining workflows, enhancing collaboration among teams, and leveraging technology to overcome geographical barriers. By embracing innovation and agility, DAZN aims to continuously improve its testing capabilities and deliver exceptional quality across its diverse range of applications and platforms.

## Challenges

DAZN employs a diverse team of developers and test engineers spread across different global locations such as Poland, India, Israel, and the UK. Each team comes with its unique set of needs and requirements, necessitating a robust, highly available, and cost-effective platform to accommodate them effectively.

Key points include:

- Diverse Platform Support:
  The platform must ensure comprehensive testing across all platforms supported by DAZN, emphasizing thoroughness and quality assurance in our testing procedures.
- Tailored Solutions:
  Teams may require different tools and resources for their testing processes; for instance, some teams may rely on manual UI/UX testing devices, while others prioritize automation solutions.
- Integration Challenges:
  Incorporating in-house tools and services into our platform is essential to ensure seamless continuity for engineers, requiring careful integration efforts.
- Scalability and Maintenance:
  The platform needs to support a large number of engineers on a daily basis across multiple global sites, balancing scalability with efficient maintenance to avoid operational bottlenecks.

- Cost Considerations:
  Maintaining devices, infrastructure, and manpower across various locations can incur significant expenses, necessitating a cost-effective approach to resource allocation and management.

- Ownership and Accountability:
  Clear ownership and accountability structures are crucial to prevent issues such as maintenance gaps or device mismanagement.

To address these challenges, ongoing efforts are focused on streamlining processes, enhancing collaboration between teams, and leveraging automation wherever possible to optimize resource utilization and improve efficiency in our testing and development workflows.

## Solution — Lab as a Service

Our team, composed of seasoned experts in DevOps, Automation Infrastructure, and IT, recognized the need for a novel solution to address the challenges faced in managing Device Under Test (DUT) usage at DAZN. In the first quarter of 2023, we conducted a comprehensive assessment to identify and map out the major pain points associated with DUT utilization within the organization. This assessment culminated in the development of a pioneering approach coined “Lab as a Service,” aimed at alleviating the burden on developers and testers by handling all DUT-related tasks and physical infrastructure management.

During the second quarter of 2023, we introduced the Minimum Viable Product (MVP) setup, leveraging the Suitest framework — a vendor offering remote control and automation capabilities tailored for both HTML-based and native platforms. Our team meticulously orchestrated the deployment of all requisite physical infrastructure, assembling a dedicated lab housing 50 test devices within a spacious room at the DAZN Katowice office.

![DUT lab v1.0 (QA room — May 2023)](https://miro.medium.com/v2/resize:fit:640/format:webp/1*MDbJo7nq77qwWrRCpNvsrA.jpeg)_DUT lab v1.0 (QA room — May 2023)_

To bolster reliability and resilience, we implemented a comprehensive monitoring and alerting system, with Grafana serving as the frontend interface. Additionally, we integrated DUT recovery mechanisms to enhance the robustness of our testing environment.

![Grafana monitoring dashboard](https://miro.medium.com/v2/resize:fit:640/format:webp/1*8a9dpHjMLH1FZCQptCNplw.png)_Grafana monitoring dashboard_

The efficacy of these enhancements became apparent swiftly, as an increasing number of engineers gravitated towards utilizing the centralized lab infrastructure instead of configuring local devices. Leveraging the valuable feedback provided by users, we iteratively refined and enhanced the lab environment, ensuring that it continues to meet the evolving needs of our development and testing teams.

## Lab as a service 2.0

As the user base and the number of devices in the DAZN lab continued to surge, spurred by the establishment of a new DAZN site in India and the expansion of supported platforms throughout the latter half of 2023, we undertook further enhancements to the Katowice lab. These adjustments were aimed at accommodating the organization’s growth and fortifying its capacity to scale even further. Throughout the first quarter, we initiated a series of improvements targeting both the physical infrastructure and supporting features:

### Infrastructure enhancements

- **Relocation and Expansion:**

The DUT lab underwent relocation to a larger space, facilitating increased scalability and the seamless onboarding of additional platforms and devices. Leveraging existing racks more efficiently, we enabled the mounting of devices on both sides of each rack, resulting in a 50% boost in the number of TVs and a 40% increase in the number of set-top boxes (STBs), totaling 120 DUTs overall, with ample room for further expansion.

![DUT lab v2.0 (open space — January 2024)](https://miro.medium.com/v2/resize:fit:640/format:webp/1*IKUuw6aU2wQMzTBKCKS_bA.jpeg)_DUT lab v2.0 (open space — January 2024)_

- **Streaming Solutions:**

Collaborating with Suitest, we identified a cost-effective solution enabling the streaming of device HDMI output for STBs and gaming consoles. Additionally, we enhanced the TV streaming setup by refining the phone streaming app.

![Live DUT Streaming Phone camera setup](https://miro.medium.com/v2/resize:fit:720/format:webp/1*K460jjXRPqXUVQf8PVg0ng.jpeg)_Live DUT streaming mobile phone camera setup_

![HDMI grabber/splitter combo](https://miro.medium.com/v2/resize:fit:640/format:webp/1*s-cKLE8Oh1h5mliovKc91Q.jpeg)_HDMI grabber/splitter combo_

### Features enhancements

- **Collaboration with Suitest:**

Over the course of the year, we actively collaborated with Suitest to influence their roadmap, contributing to improvements in user experience and interface. A significant milestone was the introduction of a Unified UI integrating video streaming, remote control, and logs within the same browser window, enhancing productivity for lab users.

![Suitest Unified UI](https://miro.medium.com/v2/resize:fit:640/format:webp/1*Wg96k859tBYZwz13vVXG3Q.png)_Suitest Unified UI_

- **LR (Living Room) Launcher**:

In collaboration with the DAZN LivingRoom development team, we introduced LR Launcher, simplifying the workflow for manual testers and streamlining the onboarding process for partner platforms such as Sky and Movistar for the sake of ease of use when testing different development environments.

![LR Launcher](https://miro.medium.com/v2/resize:fit:640/format:webp/1*5AObQs1_Vdyd9cXhf5qF3w.png)_LR Launcher_

- **Enhanced Monitoring**:

With the growing user base and device count, robust monitoring became paramount. We revamped our monitoring service, streamlining processes and transitioning from an API-based solution to WSS notifications. Furthermore, we expanded monitoring coverage and implemented alerting for control units and streaming devices.

- **Automated Recovery**:

Leveraging smart plugs across all TV platforms, we implemented remote manual and automated recovery mechanisms for malfunctioning DUTs. Efforts are underway to develop similar mechanisms for cameras and control units, bolstering the resilience and efficiency of our lab environment.

- **Local Tunnel**:

A local tunnel solution providing exposure of a local development server allows developers and testers to seamlessly execute their code on a real physical lab device. This capability not only streamlines the testing process but also provides a practical and authentic environment for validating local code during development.

- **Lab Insights Report (BI)**:

An automated report detailing lab usage and testing trends. This report will provide valuable insights into usage patterns, enabling us to further optimize our services based on real data.

![BI Report](https://res.cloudinary.com/dtt2usukl/image/upload/v1716458627/Image_27-08-2023_at_11.58_sas9dh.jpg)_BI Report_

**VPN Change Region & VPN Console**:

A VPN solution that will empower lab users to seamlessly transfer DUTs between regions remotely. Using firewalls controlled by OPNSense, a lambda backend and a UI portal written in React (NextJS) users are able to testing of region-dependent content across all lab devices by switching regions as needed.

![VPN Console](https://res.cloudinary.com/dtt2usukl/image/upload/v1716458833/Image_23-05-2024_at_13.06_oxbech.jpg)_VPN Console_

## Service & Support

- **Continuous Improvement:**

Since the launch of the DUT lab in May 2023, we have continually bolstered our service and support infrastructure. This includes expanding our support engineering team, enhancing documentation and guides, and maintaining accessible support channels during working hours. Our commitment to swift issue resolution is underscored by our expanded remote resolution capabilities, facilitated by proactive monitoring and device error-based recovery processes.

- **Onboarding Optimization:**

Through the introduction of “Lab as a Service 2.0” and tailored training sessions, we have streamlined the onboarding process for new users, ensuring a seamless transition and maximizing productivity from the outset using official docs portal (using github pages and backstage).

These enhancements collectively represent our ongoing commitment to optimizing the DAZN lab environment, fostering innovation, and empowering our engineering teams to deliver exceptional quality across all platforms and devices.

## Acknowledgements

Special thanks to the amazing AP Nexus team for their dedication and hard work, it was a pleasure working with each one of you!

[Dennis Groisman](https://www.linkedin.com/in/dennis-groisman-9811b335/), [Daniel-Shahar Cohen](https://www.linkedin.com/in/danielshaharcohen/), [Rafal Muszalik](https://www.linkedin.com/in/rafa%C5%82muszalik/), [Blazej Milewski](https://www.linkedin.com/in/blazej-milewski/), [Alex Rivkin](https://www.linkedin.com/in/alex-rivkin-b037a6a1/), [Yoav Brown](https://www.linkedin.com/in/yoav-brown-970b55265/) and the one and only [Gal Moran](https://www.linkedin.com/in/gal-moran-a3454095/).

[![DAZN Lab as a Service](https://res.cloudinary.com/dtt2usukl/image/upload/v1716460903/play_video_lab_fnkajn.jpg)](https://res.cloudinary.com/dtt2usukl/video/upload/v1716460249/tvlab_v2_withmusic_twifar.mp4 'DAZN Lab as a Service - Nexus Team')_My team - Lab as a Service 2.0_

Article on [Medium (DAZN Engineering Blog)](https://medium.com/dazn-tech/lab-as-a-service-in-dazn-9bcc9d549970)


I'm incredibly proud to share the outstanding work our team has accomplished recently in upgrading our testing lab infrastructure.

Lab as a Service in DAZN


Microsoft Authentication Library or MSAL is a library that enables web applications to authenticate users against Azure Active Directory (AAD). This setup can be crucial for applications requiring secure identity management and access control, especially within organizations using Microsoft services.

MSAL JS library supports protocols such as OAuth2 and OpenID Connect, making it easier to implement for web applications.

So let's begin.

### Registering Your Application with Azure AD

First, you need to register your application with Azure AD to obtain valid credentials for authentication.

1. Sign into the Azure Portal: Navigate to Azure Portal.
2. Create a New App Registration: Go to Azure Active Directory > App registrations > New registration. Make sure you select SPA applications.
3. Configure Redirect URIs: For development, and in my case, I used `http://localhost:3000/`. Ensure not to enable Implicit Grant or Hybrid Flows.

![Azure-SPA-Registered](/images/azure-spa-register.jpeg)

### Setting Up Your Next.js Project

Initialize a new Next.js project if you haven't already:

```bash
npx create-next-app msal-next-auth --use-npm
cd msal-next-auth
npm install @azure/msal-react @azure/msal-browser
```

### Configuring MSAL in Your Next.js App

Create a configuration file for MSAL and initialize the MSAL instance.

In my case I created a file named `msal.js` in `services/` directory:

```javascript
import { PublicClientApplication } from '@azure/msal-browser'

const msalConfig = {
  auth: {
    clientId: process.env.NEXT_PUBLIC_AZURE_AD_CLIENT_ID,
    authority: `https://login.microsoftonline.com/${process.env.NEXT_PUBLIC_AZURE_AD_TENANT_ID}`,
    redirectUri: process.env.NEXT_PUBLIC_REDIRECT_URI,
  },
}

const msalInstance = new msal.PublicClientApplication(msalConfig)
export { msalInstance }
```

Ensure you have set the environment variables in `.env.local`:

```bash
NEXT_PUBLIC_AZURE_AD_CLIENT_ID=your-client-id
NEXT_PUBLIC_AZURE_AD_TENANT_ID=your-tenant-id
NEXT_PUBLIC_REDIRECT_URI=/
```

Note that the `redirectUri` should match the one you configured in Azure AD.
Also, note that NEXT_PUBLIC env vars (browser env vars) are being applied only in during build time and not in runtime. Which means if these env vars are environment dependent, you should take it into account in your CI that handles the application build and deployment.

Next, Modify `_app.js` to Use MSAL Provider:

```javascript
import { MsalProvider } from '@azure/msal-react'
import { msalInstance } from '@/services/msal'
import '.@/styles/globals.css'

function MyApp({ Component, pageProps }) {
  return (
    <MsalProvider instance={msalInstance}>
      <Component {...pageProps} />
    </MsalProvider>
  )
}

export default MyApp
```

### Adding Authentication to Your Pages

Here you can use MSAL React hooks which makes your life easier and add authentication functionality.

For example, in `pages/index.js`:

```javascript
import {
  AuthenticatedTemplate,
  UnauthenticatedTemplate,
  useMsal,
} from '@azure/msal-react'
import React from 'react'

function SignInButton() {
  const { instance } = useMsal()
  return <button onClick={() => instance.loginRedirect()}>Sign In</button>
}

function WelcomeUser() {
  const { accounts } = useMsal()
  const username = accounts[0]?.name || 'Guest'
  return <p>Welcome, {username}</p>
}

export default function Home() {
  return (
    <div>
      <AuthenticatedTemplate>
        <WelcomeUser />
      </AuthenticatedTemplate>
      <UnauthenticatedTemplate>
        <SignInButton />
      </UnauthenticatedTemplate>
    </div>
  )
}
```

Note that you can use the token acquired from MSAL to call your API with authentication header (if required) or use any other attribute from the token object such as name from the example.

You can also use the `useIsAuthenticated` hook to check if the user is authenticated and show different content accordingly.

```javascript
import { useIsAuthenticated } from '@azure/msal-react'

export default function Home() {
  const isAuthenticated = useIsAuthenticated()
  return <div>{isAuthenticated ? <WelcomeUser /> : <SignInButton />}</div>
}
```

In one of my projects at work I created a custom hook to use the token in the API calls:

```javascript
import { useMsal } from '@azure/msal-react'

export const useAccessToken = () => {
  const { instance, accounts } = useMsal()
  const account = accounts[0]

  const getAccessToken = async () => {
    try {
      const request = {
        scopes: [`${process.env.NEXT_PUBLIC_CLIENT_ID}/.default`],
        account: account,
        redirectUri: '/',
      }

      const response = await instance.acquireTokenSilent(request)
      return response.accessToken
    } catch (error) {
      console.log('error', error)
      if (error instanceof InteractionRequiredAuthError) {
        instance.acquireTokenRedirect(request)
      } else {
        throw error
      }
    }
  }

  return getAccessToken
}
```

And just for the sake of the example, one of components which uses the the custom hook which fetches the accessToken from AAD and sending as Authentication header in one if its API calls:

```javascript
import React, { useState, useEffect } from 'react';
import { useMsal } from '@azure/msal-react';

import { useAccessToken } from '@hooks/useToken';

const DeviceTable = () => {
  const getAccessToken = useAccessToken();
  const [regions, setRegions] = useState({});
  const [error, setError] = useState(null);

  useEffect(() => {
    let apiUrl = '';

    const fetchConfigAndData = async () => {
      try {
        const accessToken = await getAccessToken();

        const regionsData = await fetch(`${apiUrl}/api/v1/devices`, {
          headers: {
            'Authorization': `Bearer ${accessToken}`
          }
        }).then(res => res.json());
        setRegions(regionsData);
      } catch (error) {
        setError(error);
      }
    };

    fetchConfigAndData();
  }, []);
```

Keep in mind that i'm not an experienced frontend developer, so the code above might not be the best practice, but it works for me. I'll be happy to hear your feedback and suggestions. I'm mostly available on [Linkedin](https://www.linkedin.com/in/kazaz-or/).


Learn how to integrate Azure AD authentication into your Next.js app using MSAL library for security and user management.

Integrating Azure AD Authentication in Your Next.js App Using MSAL


Ensuring consistent application performance across multiple platforms is a cornerstone of quality software delivery. In this post, I'll share my approach for using GitHub Actions to automate testing across a variety of platforms, drawing from a real use case at my workplace.

Our solution utilizes GitHub Actions, a CI/CD service that enables automation of build, test, and deployment workflows directly within GitHub. The highlight of the approach is the dynamic matrix strategy, which handles both scheduled runs and on-demand tests across specified platforms.

**Scheduled and On-demand Testing**

In this example, the workflow is being triggered automatically at 22:00 every day for nightly tests. Additionally, we enabled manual triggers for specific platforms, allowing for targeted testing as needed. This flexibility is crucial for maintaining a fast-paced development cycle without compromising on quality.

```yaml
on:
  schedule:
    - cron: '0 22 * * *'
  workflow_dispatch:
    inputs:
      platform:
        description: 'Choose platform to run the test on'
        required: true
        type: choice
        options:
          - webos
          - tizen
          - playstation4
          - playstation5
          - xbox
```

This configuration leverages the `schedule` and `workflow_dispatch` events in GitHub Actions. The `cron` syntax schedules automated test runs, while `workflow_dispatch` allows for manual execution with platform-specific parameters.

**Dynamic Test Matrix Configuration**

The core of our workflow dynamically adjusts the test matrix based on the context of the trigger—whether it's a scheduled job covering all platforms or a manual job focusing on a specific platform.

```yaml
jobs:
  setup-test:
    runs-on: ubuntu-latest
    outputs:
      platform: ${{ steps.set-matrix.outputs.platform }}
    steps:
      - id: set-matrix
        run: |
          if [ "${{ github.event_name }}" = "schedule" ]; then
            echo 'platform=["webos", "tizen", "playstation4", "playstation5", "xbox"]' >> $GITHUB_ENV
          else
            echo 'platform=["${{ github.event.inputs.platform }}"]' >> $GITHUB_ENV
```

In this snippet, we employ conditional logic to populate the platform variable differently based on the trigger type. For scheduled runs, we test across all platforms, while manual triggers allow for focused testing on a selected platform. This strategy ensures that resources are allocated efficiently, focusing our testing efforts where they are most needed.
Of course, you could always do that with an external script or with a composite action, but this is a simple and effective way to achieve the same result.

**Executing the Tests with Dynamic Configuration**

Our approach to executing tests in this workflow benefits significantly from the dynamic nature of GitHub Actions, especially when it comes to handling multiple platforms which can be quite different from each other. This flexibility is further extended into our application's `package.json` file, where we define specific scripts for our testing needs. The `package.json` plays a crucial role in integrating the GitHub environment variables directly into our test execution process.

Without getting into the tests code, you can imagine that each platform has its own specific tests and configurations, and that's why we need to run the tests separately for each platform. This is where the dynamic matrix comes into play.

```yaml
- name: Run tests
  working-directory: ./src/lr-launcher-e2e
  env:
    npm_config_env: ${{ matrix.platform }}
  run: npm test
```

Here, the `npm test` command is executed within the context of each platform specified by the dynamic matrix. This ensures that our E2E tests are relevant and efficient, automatically adapting to the complexities of multi-platform support.

Here's a look at the relevant part of our `package.json` file:

```json
{
  "name": "lr-launcher",
  "version": "1.0.0",
  "scripts": {
    "pre-test": "node ./utils/setupTest.js --",
    "test": "mocha \"tests/*.test.js\" \"tests/$npm_config_env/*.test.js\" --no-timeouts --retries 1 --exit"
  },
  "dependencies": {
    "axios": "^1.6.2",
    "mocha": "^10.2.0"
  }
}
```

This script utilizes the `npm_config_env` environment variable, which we set dynamically based on the selected platform in our GitHub Actions workflow. By incorporating `$npm_config_env` into the mocha command, we ensure that the test runner picks up not only the general tests from tests/_.test.js but also platform-specific tests located in directories named after each platform (e.g., tests/webos/_.test.js).

This setup allows us to maintain a clear and organized test structure where platform-agnostic tests are separated from those that are platform-specific. It ensures that when our GitHub Actions workflow runs, it only executes the relevant tests for the specified platform, making our testing process both efficient and comprehensive.


Automate cross-platform testing with GitHub Actions, using dynamic matrices for efficient, targeted tests.

GitHub Actions for Dynamic Cross-Platform Testing


While working on a project at work, I delved into unit tests with Sinon v8. I discovered that unit tests using Sinon can sometimes pose challenges, so here's a glimpse of what I learned.
For this project I used Mocha as a test runner, Chai for assertions, Sinon for mocking and Proxyquire for sandboxing.

This is our demo app code that we will be using for this article. It is a simple Node.js application that manipulates files on the file system.

```js
const {
  readdir,
  readdirSync,
  readFileSync,
  unlinkSync,
  writeFileSync,
} = require('fs')
const util = require('util')

module.exports = {
  createFile: filename => {
    if (!filename) {
      throw new Error('Must supply file name')
    }

    return writeFileSync(`./data/${filename}`, '', { flag: 'wx' })
  },
  createFileInjected: (filename, fs) => {
    if (!filename) {
      throw new Error('Must supply file name')
    }

    return fs.writeFileSync(`./data/${filename}`, '', { flag: 'wx' })
  },
  createFileSafe: filename => {
    if (!filename) {
      throw new Error('Must supply file name')
    }

    try {
      const result = writeFileSync(`./data/${filename}`, '', { flag: 'wx' })
    } catch (error) {
      const files = readdirSync('./data')
      const [name, extension] = filename.split('.')

      let max =
        files
          .filter(f => f.match(/test[1-9]/))
          .map(f => Number(f.replace(name, '').replace(`.${extension}`, '')))
          .sort()
          .pop() || 0

      const newName = `${name}${++max}.${extension}`
      writeFileSync(`./data/${newName}`, '', { flag: 'wx' })
    }
  },
  deleteFile: filename => {
    if (!filename) {
      throw new Error('Must supply file name')
    }

    return unlinkSync(`./data/${filename}`)
  },
  getFile: filename => {
    if (!filename) {
      throw new Error('Must supply file name')
    }

    return readFileSync(`./data/${filename}`)
  },
  getAllFiles: cb => {
    readdir('./data', cb)
  },
  getAllFilesPromise: () => {
    const readPromise = util.promisify(readdir)
    return readPromise('./data')
  },
  saveFile: (filename, contents) => {
    if (!filename) {
      throw new Error('Must supply file name')
    }

    return writeFileSync(`./data/${filename}`, contents)
  },
}
```

### Spies

Spies are a good choice for monitoring functions - such as tracking logs, check if a function is being called, etc. You can think about it as Spies are good at answering questions about your methods.

Consider this potentially misleading use case for a spy:

```js
describe('File Management', () => {
  afterEach(() => {
    sinon.restore()
  })

  it('Should create a new file', () => {
    const writeSpy = sinon.spy(fs, 'writeFileSync')
    const fileManagement = proxyquire('./file.management', { fs })

    fileManagement.createFile('test.txt')
    expect(writeSpy.calledWith('./data/test.txt', '')).to.be.true
  })
})
```

In the given example, the test might pass once but fail on subsequent runs due to an existing `test.txt` file, causing an exception. Spies don't always prevent such side effects. In situations like these, Stubs can be a better choice.

### Stubs

Stubs ensure safety during testing. They can manipulate functions and handle side effects like calling APIs or interacting with third-party libraries.
The common stub approaches are side effects like returning a specific values (basically override the original function return value), throw exceptions, resolve or reject promises to understand the function behavior according to real use cases, or call a separate fake function in order to keep the function under test isolated.
There are also other common use cases such as saving time in your tests if you have function with longer execution time.

Using our previous example but with a stub:

```js
describe('File Management', () => {
  afterEach(() => {
    sinon.restore()
  })

  it('Should create a new file', () => {
    const writeStub = sinon.stub(fs, 'writeFileSync')
    const fileManagement = proxyquire('./file.management', { fs })

    fileManagement.createFile('test.txt')

    expect(writeStub.callCount).to.equal(1)
  })
})
```

Here, no actual file is created since we override the `writeFileSync` function, making repeated test runs consistent. It's due to the fact that we override the `writeFileSync` function using a stub. Meaning that unlike the spy use case, I can now run the test multiple times and it won’t fail after the first execution.

But what if we actually want to check that in the use case of file already exists an exception is raised?

We can modify our stub for the dependent `writeFileSync` function to throw an exception and then check that createFile function is behaving as expected.

such as follows:

```js
it('Should throw an exception if file already exists', () => {
  const writeStub = sinon.stub(fs, 'writeFileSync')
  writeStub.throws(new Error())
  const fileManagement = proxyquire('./file.management', { fs })

  expect(() => fileManagement.createFile('test.txt')).to.throw()
})
```

But in most production cases, you’d like to throw an exception based on the actual use case, not every time.
So we can configure our stub to throw exception only in a specific case (which is our test case) using the `withArgs` Sinon function.

```js
it('createFileSafe should create a file named test1 when test file already exists', () => {
  const writeStub = sinon.stub(fs, 'writeFileSync')
  const readStub = sinon.stub(fs, 'readdirSync')

  const fileManagement = proxyquire('./file.management', { fs })

  writeStub.withArgs('./data/test.txt').throws(new Error())
  writeStub.returns(undefined)
  readStub.returns(['test.txt'])
})
```

You can see that in this case we throw an exception only when the function is being called with this specific argument of test file ("./data/test.txt").

Another common example, is to check what happens if `createFile` function is being called without required argument.

```js
it('Should not create a new file if no name is specified', () => {
  const writeStub = sinon.stub(fs, 'writeFileSync')
  const fileManagement = proxyquire('./file.management', { fs })

  try {
    fileManagement.createFile()
  } catch (err) {}
  expect(writeStub.notCalled).to.be.true
})
```

Thing we need to take into account is if the function throws an exception, we have to wrap the call in the function of our test with a try-catch block and then make the assertion.

Now let's explore an Async use case.

Async functions bring a bit of complexity, so understanding JS callbacks helps. In Node, callbacks typically have an error as their first parameter and the return value as the second.

```js
;(Err, data) => {}
```

So in such cases you can emulate a returned callback using Sinon's `yields` function.

```js
it('getAllFiles should return a list of files', () => {
  const readStub = sinon.stub(fs, 'readdir')
  const fileManagement = proxyquire('./file.management', { fs })
  readStub.yields(null, ['test.txt'])

  fileManagement.getAllFiles((err, data) => {
    expect(data).to.eql(['test.txt'])
  })
})
```

Couple of things to note;

In the test we should make the assertion inside a callback.

The stub yields null as the err parameter, and the array with the file name as the data of the callback.

While yield is nice to emulate callbacks, a lot of applications have moved to promises instead, so let’s see how we can deal with promises as well.

```js
it('getAllFilesPromise should return a list of files', () => {
  const readStub = sinon.stub(fs, 'readdir')

  const fileManagement = proxyquire('./file.management', { fs })
  readStub.resolves(['test.txt'])

  return fileManagement
    .getAllFilesPromise()
    .then(files => expect(files).to.eql(['test.txt']))
})
```

As you can see, you can just tell the stub to resolve or reject the promise using the data you’d expect.

There is another important use case with Sinon, which is using `callsFake`.
callsFake function usually return a single argument, but unlike `returns` and `yields`, it is used to return a function.

Why would I want to return a function? One example, is if I have some logic I want to execute.

For example, here I’ll use the spread operator to gain access in the stub to the arguments:

```js
const writeStub = sinon.stub(fs, “writeFileSync”).callsFake((...args) => {});
```

The receiving arguments in this case are `“./data/test.txt”`, `""`, `{ flag: “wx” }`.

You can also add behavior to a function (although I think it is less common) using the `addBehavior` function.

```js
sinon.addBehavior(“logsCall”, (fake, msg) => {
	console.log(msg)’
});
```

Then you can use this new defined behavior as a method on your stub.

But two important notes on `addBehavior`; Behaviors must be defined before the stubs, but they can be also chained.

So you want, you can do something like this:

```js
myStub.logsCall(“called”).returns(“hi”);
```

### Fakes

Unlike Stubs, Fakes are immutable and don't replace the default function behavior automatically.

So let’s see the differences.

Replacing a Spy with a Fake:

```js
it('Should create a new file', () => {
  const writeFake = sinon.fake(fs.writeFileSync)
  sinon.replace(fs, 'writeFileSync', writeFake)
  const fileManagement = proxyquire('./file.management', { fs })

  fileManagement.createFile('test.txt')

  expect(writeFake.calledWith('./data/test.txt', '')).to.be.true
})
```

Note that unlike stub, fake receives one argument (which in our case it is the `module.function`).
Also, note that I had to specify (using Sinon’s replace function) what will be the behavior or else it will act as the default behavior.
The `replace` function takes 3 arguments (module, function and the return fake).

In the case above, the test will pass but will fail after another execution due to the same issue we had with our Spy (text.txt) file is created.

Replacing a Stub with a Fake:

One important concept, is instead of faking the function (as you do with Stubs), you use the property, not the function, then using Sinon’s replace function, override the default behavior.

```js
it('Should throw an exception if file already exists', () => {
  const writeFake = sinon.fake.throws(new Error())
  sinon.replace(fs, 'writeFileSync', writeFake)
  const fileManagement = proxyquire('./file.management', { fs })

  expect(() => fileManagement.createFile('test.txt')).to.throw()
})
```

Now let’s do the same for an async function:

```js
it('getAllFiles should return a list of files', () => {
  const readFake = sinon.fake.yields(null, ['test.txt'])
  sinon.replace(fs, 'readdir', readFake)
  const fileManagement = proxyquire('./file.management', { fs })

  fileManagement.getAllFiles((err, data) => {
    expect(data).to.eql(['test.txt'])
  })
})
```

I had to chain the behavior or else the test will fail.

Most of the use cases which using Fakes are usually when you only need one behavior (not based on things like different arguments, etc).

### Mocks

Basically, we do not have re-define what a mock is because it’s pretty strait forward, although it’s a matter of practice. With mocks you first define what to expect and then assert on it.

If we compare it to Stubbing, you’ll need to do something like this:

```js
// stub
myStub.returns(1);
Const result = myStub();
expect(result).to.eql(1);
```

With mocks however it’s almost inverted, for example:

```js
// mock
expect(myStub).to.return(1) // setting expectation first
myStub() // then calls the function
```

Let’s use one of our “real” example as above:

```js
it('Should call writeFileSync when creating a file', () => {
  const writeMock = sinon.mock(fs)
  writeMock.expects('writeFileSync').once().withArgs('./data/test.txt', '')
  const fileManagement = proxyquire('./file.management', { fs })

  fileManagement.createFile('test.txt', '')

  writeMock.verify()
})
```

You can note that I’m mocking an entire module (`fs` module in this case).
I’m setting expectation first using the `expects` function and then asserts using the `verify` function.
Same as stubs, the test will pass but the test.txt file won’t be created and that’s because the mock is intercepting the function under test just like a stub does.

Let's take a look at another test case:

```js
it('createFileSafe should created a new file with a number appended', () => {
  const writeMock = sinon.mock(fs)
  writeMock.expects('writeFileSync').withArgs('./data/test.txt').throws()
  writeMock.expects('writeFileSync').withArgs('./data/test1.txt').once()
  writeMock.expects('readdirSync').returns(['test.txt']).once()
  const fileManagement = proxyquire('./file.management', { fs })

  fileManagement.createFileSafe('test.txt')

  writeMock.verify()
})
```

What if we want to check a function was NOT called?

```js
it('createFile should never call writeFileSync when the file is empty', () => {
  const writeMock = sinon.mock(fs)
  writeMock.expects('writeFileSync').never()

  const fileManagement = proxyquire('./file.management', { fs })

  try {
    fileManagement.createFile()
  } catch (err) {}

  writeMock.verify()
})
```

As you can see, it’s pretty strait forward, you can just utilize the `never()` function.

### To conclude

**Spies** are great for answering questions such as how many times is this function called, with which argument, etc.
It’s considered as bad practice to try and control a function.

**Stubs** is like a stunt double - It keeps us safe from all the side effects of the functions under test like exceptions, calls for APIs or a third party application/libraries, and in any case of forcing a behavior like throwing exception, it’s the stub that does it, not the actual function under test.

**Fake** is a method to combine the two together, they ask questions AND defines behavior.
It has the ability to set a behavior, record arguments, return values, emulates exceptions and more.

Unlike Stubs, Fakes are immutable, and do not replace automatically the original functions behavior.
Unlike stubs, you cannot modify its behavior based on received args or the number of times it’s called, and there are couple of missing functions that are commonly being used with stubs such as `callsFake()`, `callsThrough()` and `addBehavior()`.

**Mocks** - With mocks you first define what to expect and then assert on it and usually you mock an entire module instead of a specific function.

Unlike Fakes, Mocks do contains all of the Spies and Stubs function, with some additional function on top of it (like `never()`, `atLeast()` AND `atMost()`).

As you can see there’s a lot of commonality in all those test doubles, but also some uniqueness in each one of them.

_Code examples were taken from [Nate Taylor PluralSight Course on Mocking Node JS with Sinon](https://app.pluralsight.com/library/courses/mocking-nodejs-sinon). Highly recommended!_


Unit testing and mocking in Node.js with Sinon, get familiar with basic Spies, Stubs, Fakes, and Mocks, concepts.

Explore Mocking In Node.js Using Sinon


Before we dive into hands on examples of such validation, let's first understand what is AJV library and see what other options I explored at work when I was in charge of a task to implement such validator in one of our JS services.

The more "Generic" way - [AJV](https://www.npmjs.com/package/ajv)

The "JS syntax" way - [Joi](https://www.npmjs.com/package/joi)

## AJV

The big win you get from JSON Schema is that it's cross platform. JSON Schema validator implementations exist in every major programming language. No matter what language you choose, you can use the same JSON Schema on the frontend and the backend and get consistent validation results. Write once, validate anywhere.

The downside is that because it's cross platform, it's also somewhat limited in what it can do. It's purposely kept simple enough so that it's not too difficult to implement in any programming language. Because JSON Schema isn't a full fledged programming language, it's limited in what it can do. Although I admit, I still haven't encountered with a scenario where I couldn't find a way to validate something.

## Joi

Joi's biggest advantage is its usability. It's easy to use, easy to extend, and it has the full power of JavaScript.

The downside is that if you want to reuse your validation logic on the frontend and the backend, your only choice of language on the backend is node.

You might choose Joi if you use JavaScript for the frontend and the backend and don't anticipate non-JavaScript clients that you need to support. This is a fairly narrow situation, but if it is your situation, you will likely get more out or Joi than AJV/JSON Schema.

## So let's move on to some comparison i've made

Two things really stood out to me and decided were in terms of performance and popularity.

**Performance**

There are many resources out there that compares both libraries performance, but I it's not even close (and to be fair, it's like comparing oranges to apples). AVJ is way faster.
Here are a few resources I found back then -

- [https://github.com/hapijs/joi/issues/1601](https://github.com/hapijs/joi/issues/1601)
- [https://github.com/icebob/validator-benchmark](https://github.com/icebob/validator-benchmark)

As I said - Not even close.

**Popularity**

Github stars aren't a great measure of popularity. If you look at npm daily downloads you see a very different story (AJV: 18.9M, Joi: 2.2M). JSON Schema is by far more widely used because it is cross platform. AJV is just one implementation in one language. But, if your development stack fits Joi's particular niche, it can be just as good a choice or a better choice than JSON Schema.

![npm-ajv-vs-joi](/images/npm-ajv-vs-joi.jpeg)

Here's a nice [NPMCompare](https://npmcompare.com/compare/ajv,joi,schema-inspector) resource I used.

## That's pretty much it. Let's move on to some AJV and Json Schema examples

For the sake of the example, we'll start with an express route which its post method has an api validator middleware where we're passing the schema and validation type (body, params, query, etc..). In this case we'll use validator for the body of the request.

**Route:**

```js
const router = express.Router()

// Define a route to '/devices', with GET and POST methods.
// For POST requests, an API validation middleware is applied to check the request body against a schema.
router
  .route('/devices')
  .get(
    getDevices() // business logic
  )
  .post(
    apiValidator(postDeviceSchema, validationType.BODY), // validation middleware
    postDevices() // business logic
  )
```

**Generic validation middleware:**

```js
const Ajv = require('ajv')
const addFormats = require('ajv-formats')

// Create an instance of AJV, adding all formats for validation.
const ajvInstance = new Ajv({ allErrors: true })
addFormats(ajvInstance)

// Define the types of validations that can be performed.
const validationType = {
  PARAMS: 'params',
  BODY: 'body',
}

// Create an API validator middleware function. This function uses AJV to validate the data
// of the request (either body or params) against a provided schema.
// If the data is not valid, an error is returned.
function apiValidator(schema, type) {
  return (req, res, next) => {
    try {
      let data = null
      if (type === validationType.BODY) {
        data = req.body
      } else if (type === validationType.PARAMS) {
        data = req.params
      }
      const ajvValidate = ajvInstance.compile(schema)
      const valid = ajvValidate(data)
      if (!valid) {
        const errors = ajvValidate.errors
        res.status(400).json(errors)
        return
      }
      next()
    } catch (err) {
      res
        .status(500)
        .json({ message: 'Internal Server Error, Failed to validate request' })
    }
  }
}
```

The `apiValidator` middleware takes a schema and the type of validation to be performed (e.g., BODY or PARAMS). The middleware compiles the schema using AJV and validates the request data against it. If the validation fails, it sends a 400 status response detailing the errors.

**Post device schema:**

```js
// Base schema for device data. This includes various properties that the device should have,
// along with their expected types and constraints.

const deviceProperties = {
  deviceName: { type: 'string' },
  manufacturer: { type: 'string', enum: config.get('allowedManufacturers') },
  model: { type: 'string', minLength: 3, maxLength: 30 },
  os: { type: 'string', enum: config.get('allowedOs') },
  osVersion: { type: 'string', minLength: 1, maxLength: 30 },
  serialNumber: { type: 'string', minLength: 5, maxLength: 30 },
  site: { type: 'string', enum: config.get('allowedSite') },
  ipAddress: {
    type: 'string',
    anyOf: [{ format: 'ipv4' }, { format: 'ipv6' }],
  },
}

// Extended schema for POST requests. This extends the base device schema,
// adding a requirement for each property and disallowing additional properties.

const postDeviceSchema = {
  type: 'object',
  properties: deviceProperties,
  required: [
    'deviceName',
    'manufacturer',
    'model',
    'os',
    'osVersion',
    'serialNumber',
    'site',
    'ipAddress',
  ],
  additionalProperties: false,
}
```

So what do we have in the schemas that isn't obvious like expecting a string and min/max length?

`manufacturer`: A string that must be one of the allowed manufacturers. The list of allowed manufacturers is retrieved from the application's configuration (using config.get('allowedManufacturers')). The use of the enum keyword ensures that the manufacturer value provided must match one of the ones in this list.

`ipAddress`: A string that must be either an IPv4 or IPv6 address. This is accomplished by providing an array of schema objects to the `anyOf` keyword. Each schema object has a format keyword, which AJV uses to match the data to a specific data format. In this case, the ipAddress property value will be checked against both the IPv4 and IPv6 formats, and if it matches either, it will be considered valid.

For the `postDeviceSchema`, all these properties are required, and no additional properties are allowed (enforced by additionalProperties: false). This means a valid device object must have all of these properties and cannot have any other properties.

There are many other options available in JSON Schema, such as regex (which is used as `pattern`, and many different formats such as data, uuid, etc).

Now let's see some practical use cases?

In the following example, we'll demonstrate a scenario in which a POST request fails validation because the request body doesn't match our defined postDeviceSchema.

Here's the example payload for the request:

```json
{
  "deviceName": "TestDevice",
  "manufacturer": "UnknownManufacturer", // this manufacturer is not in the allowed list
  "model": "Model1",
  "os": "OS1",
  "osVersion": "1.0",
  "serialNumber": "12345",
  "site": "Site1",
  "ipAddress": "192.168.1.1"
}
```

In this example, the manufacturer is "UnknownManufacturer", which is not in the allowed list defined in postDeviceSchema. When the request is sent, the apiValidator middleware will compare the request body with postDeviceSchema. Since "UnknownManufacturer" is not an allowed value, ajvValidate(data) will return false, indicating the validation failed.

The middleware will then gather the error information from ajvValidate.errors and send a 400 status response with the error details. This allows the client to understand what part of the request was invalid and take corrective action.

Here's an example of what the error response could look like:

```json
[
  {
    "keyword": "enum",
    "dataPath": ".manufacturer",
    "schemaPath": "#/properties/manufacturer/enum",
    "params": {
      "allowedValues": ["Manufacturer1", "Manufacturer2", "Manufacturer3"]
    },
    "message": "should be equal to one of the allowed values"
  }
]
```

The keyword tells us that the error relates to an 'enum' check. dataPath shows where in the data the error occurred, and schemaPath shows where in the schema the error was defined. params gives us additional context, such as what the allowed values for this field are. Finally, message provides a human-readable description of the error.

This kind of detailed error response is beneficial for debugging and allows clients to easily understand and correct their mistakes.

Adding to this, there are many other features which weren't covered in this blog post but AJV can handle without any issues, such as `Nested schema validation`, `Async validation` and `Custom validation keywords`.


AJV & Json Schema, a generic yet effective method for JavaScript API request validation

API Validation with AJV and Json Schema


Cypress.io offers an intuitive approach to REST API testing, primarily due to its user-friendly design and well-structured documentation. The platform supports JavaScript, which simplifies the learning curve for developers already familiar with it. Additionally, Cypress.io's real-time reloading feature allows for efficient test development, as developers can observe test results instantaneously without manually refreshing the test runner.

Furthermore, the platform's robust API enables seamless handling of network requests and responses, providing developers with comprehensive tools to test and validate various REST API endpoints. By incorporating Cypress.io's built-in assertions and custom commands, developers can create test suites with enhanced readability and maintainability.

But, Let's take it the practical way - It's better to start with some examples.

So for the sake of the example, let's create a small express application with some register and login endpoints, install a data validation library (Joi), and create some basic user model.

Source code can be found in this [repository](https://github.com/Kazaz-Or/automation-projects/tree/develop/APITestingUsingCypress).

So i'll start with the data validation Schemas, which are quite straightforward. First, create a `dataValidation.js` file in your root directory of your project. As you can tell, i used `Joi` library (`npm install joi`).

```javascript
const Joi = require('@hapi/joi')

class DataValidation {
  static registerValidation(request) {
    const validationSchema = Joi.object({
      name: Joi.string().min(2).required(),
      email: Joi.string().min(6).required().email(),
      password: Joi.string().min(8).required(),
    })
    return validationSchema.validate(request)
  }

  static loginValidation(request) {
    const validationSchema = Joi.object({
      email: Joi.string().min(6).required().email(),
      password: Joi.string().min(8).required(),
    })
    return validationSchema.validate(request)
  }
}

module.exports = { DataValidation }
```

Next, Let's create a user model Scheme using `mongoose` (can be installed with `npm install mongoose`). Create a file called Users.js under model directory.

```javascript
const mongoose = require('mongoose')

const userSchema = new mongoose.Schema({
  name: {
    type: String,
    required: true,
    min: 6,
    max: 255,
  },
  email: {
    type: String,
    required: true,
    min: 6,
    max: 255,
  },
  password: {
    type: String,
    required: true,
    min: 6,
    max: 1000,
  },
  date: {
    type: Date,
    default: Date.now,
  },
})

module.exports = mongoose.model('User', userSchema)
```

Finally, we can create are endpoints under routes directory. Note, that I used `express` and `bcryptjs` here.
Now, create a file named auth.js under routes directory, and let's create two routes - once for registration, and one for login.

```javascript
const router = require('express').Router()
const User = require('../model/Users')
const { DataValidation } = require('../dataValidation')
const bcrypt = require('bcryptjs')
const Users = require('../model/Users')

router.post('/register', async (req, res) => {
  const { error } = DataValidation.registerValidation(req.body)
  if (error) return res.status(400).send(error.details[0].message)

  const emailExists = await User.findOne({ email: req.body.email })
  if (emailExists) return res.status(400).send('Email already exists')

  const encryptedPassword = await bcrypt.hash(req.body.password, 10)

  const user = new User({
    name: req.body.name,
    email: req.body.email,
    password: encryptedPassword,
  })
  try {
    const savedUser = await user.save()
    res.send(savedUser)
  } catch (err) {
    res.status(400).send(err)
  }
})

router.post('/login', async (req, res) => {
  const { error } = DataValidation.loginValidation(req.body)
  if (error) return res.status(400).send(error.details[0].message)

  const userExists = await Users.findOne({ email: req.body.email })
  if (!userExists) return res.status(400).send('Email not found')

  const validPassword = await bcrypt.compare(
    req.body.password,
    userExists.password
  )
  if (!validPassword) return res.status(401).send('Invalid password')

  res.status(200).send('Logged in successfully')
})

module.exports = router
```

If you want to make sure everything works correctly, simply start the application `npm start`, and you can just send requests to both endpoints by using cURL.

```bash
register endpoint:

curl -d '{"name": "Kazi Tester", "email": "kazi@dev.io", "password": "simplepass"}' -H "Content-Type: application/json" http://localhost:3000/api/user/register

login endpoint:

curl -d '{"email": "kazi@dev.io", "password": "simplepass"}' -H "Content-Type: application/json" http://localhost:3000/api/user/login
```

## And now let's get to testing!

First, Let's install Cypress `npm install cypress`.

Once done, under e2e directory, let create two files, one for each route - `login.spec.cy.js` and `register.spec.cy.js`.

Starting with the register endpoint:

I installed the `guid` library just for the sake of easy randomization of users creation (of course, this method shouldn't be used in a real production testing environment, this is just for the sake of example).

So I guess this route is quite basic, therefore, let's write some sanity tests first which will assert (or more precise expect), on status code and correct response.

```javascript
const registerEndpoint = 'http://localhost:3000/api/user/register'
const Guid = require('guid')

describe('User Registration - Sanity', () => {
  it('User Registration - Status Code 200', () => {
    let dynamicEmail = Guid.raw() + '@example.com'
    cy.request({
      method: 'POST',
      url: registerEndpoint,
      body: {
        name: 'tester',
        email: dynamicEmail,
        password: '12345678',
      },
    }).then(response => {
      expect(response.status).to.equal(200)
    })
  })

  it('User Registration - Response', () => {
    let dynamicEmail = Guid.raw() + '@example.com'
    cy.request({
      method: 'POST',
      url: registerEndpoint,
      body: {
        name: 'tester',
        email: dynamicEmail,
        password: '12345678',
      },
    }).then(response => {
      expect(response.body.name).to.equal('tester')
      expect(response.body.email).to.equal(dynamicEmail)
      expect(response.body.password).to.not.equal('123456')
    })
  })
})
```

The first test checks if the response status code is 200 (OK) when a user registration request is made with valid data. A unique email address is generated using the Guid library, and a POST request is made to the registration endpoint with a predefined name, the dynamic email, and a password.

The second test, verifies if the response contains the correct name, email, and password fields. The test checks if the name matches the provided input, the email address matches the generated dynamic email, and the password does not match the plain-text password provided in the request. This test ensures that the registration API is functioning correctly and returning the expected results.

Let's move on to some schema validation tests.

```javascript
describe('User Registration - Schema Fields Validation', () => {
  it('User Registration missing name field', () => {
    let dynamicEmail = Guid.raw() + '@example.com'
    cy.request({
      method: 'POST',
      url: registerEndpoint,
      failOnStatusCode: false,
      body: {
        email: dynamicEmail,
        password: '12345678',
      },
    }).then(response => {
      expect(response.status).to.equal(400)
      expect(response.body).to.equal('"name" is required')
    })
  })

  it('User Registration missing email field', () => {
    cy.request({
      method: 'POST',
      url: registerEndpoint,
      failOnStatusCode: false,
      body: {
        name: 'tester',
        password: '12345678',
      },
    }).then(response => {
      expect(response.status).to.equal(400)
      expect(response.body).to.equal('"email" is required')
    })
  })

  it('User Registration missing password field', () => {
    let dynamicEmail = Guid.raw() + '@example.com'
    cy.request({
      method: 'POST',
      url: registerEndpoint,
      failOnStatusCode: false,
      body: {
        name: 'tester',
        email: dynamicEmail,
      },
    }).then(response => {
      expect(response.status).to.equal(400)
      expect(response.body).to.equal('"password" is required')
    })
  })

  it('User Registration name field under minimum chars', () => {
    let dynamicEmail = Guid.raw() + '@example.com'
    cy.request({
      method: 'POST',
      url: registerEndpoint,
      failOnStatusCode: false,
      body: {
        name: 't',
        email: dynamicEmail,
        password: '12345678',
      },
    }).then(response => {
      expect(response.status).to.equal(400)
      expect(response.body).to.equal(
        '"name" length must be at least 2 characters long'
      )
    })
  })

  it('User Registration email field invalid email', () => {
    cy.request({
      method: 'POST',
      url: registerEndpoint,
      failOnStatusCode: false,
      body: {
        name: 'test-user',
        email: 'tester.example.com@',
        password: '12345678',
      },
    }).then(response => {
      expect(response.status).to.equal(400)
      expect(response.body).to.equal('"email" must be a valid email')
    })
  })

  it('User Registration password field under minimum chars', () => {
    let dynamicEmail = Guid.raw() + '@example.com'
    cy.request({
      method: 'POST',
      url: registerEndpoint,
      failOnStatusCode: false,
      body: {
        name: 'test-user',
        email: dynamicEmail,
        password: '1234567',
      },
    }).then(response => {
      expect(response.status).to.equal(400)
      expect(response.body).to.equal(
        '"password" length must be at least 8 characters long'
      )
    })
  })

  it('User Registration name field wrong type', () => {
    let dynamicEmail = Guid.raw() + '@example.com'
    cy.request({
      method: 'POST',
      url: registerEndpoint,
      failOnStatusCode: false,
      body: {
        name: 5352,
        email: dynamicEmail,
        password: '1234235967',
      },
    }).then(response => {
      expect(response.status).to.equal(400)
      expect(response.body).to.equal('"name" must be a string')
    })
  })

  it('User Registration password field wrong type', () => {
    let dynamicEmail = Guid.raw() + '@example.com'
    cy.request({
      method: 'POST',
      url: registerEndpoint,
      failOnStatusCode: false,
      body: {
        name: '5352user',
        email: dynamicEmail,
        password: 1235674533,
      },
    }).then(response => {
      expect(response.status).to.equal(400)
      expect(response.body).to.equal('"password" must be a string')
    })
  })

  it('User Registration email field wrong type', () => {
    cy.request({
      method: 'POST',
      url: registerEndpoint,
      failOnStatusCode: false,
      body: {
        name: '5352user',
        email: true,
        password: '1235674pass',
      },
    }).then(response => {
      expect(response.status).to.equal(400)
      expect(response.body).to.equal('"email" must be a string')
    })
  })
})
```

These tests are a series of schema validation tests. They are focusing on verifying that the API correctly handles and responds to requests with missing or invalid data in the request body.

Each test within the suite targets a specific scenario where a required field is either missing, has an invalid value, or has a value that does not meet the required constraints.

The tests cover the following scenarios:

Missing name field in the request body
Missing email field in the request body
Missing password field in the request body
Name field with fewer than the minimum required characters
Email field with an invalid email address
Password field with fewer than the minimum required characters
Name field with an incorrect data type (number instead of a string)
Password field with an incorrect data type (number instead of a string)
Email field with an incorrect data type (boolean instead of a string)
For each test, a POST request is made to the registration endpoint with the specific invalid data, and the response is checked for the expected status code (400) and an appropriate error message. These tests ensure that the registration API correctly validates the request body schema and provides meaningful error messages for invalid data.

So far so good - Why not create some negative tests cases as well?

```javascript
describe('User Registration - Negative Cases', () => {
  it('User Registration without payload - Response 400', () => {
    cy.request({
      method: 'POST',
      url: registerEndpoint,
      failOnStatusCode: false,
    }).then(response => {
      expect(response.status).to.equal(400)
      expect(response.body).to.equal('"name" is required')
    })
  })

  it('User Registration - Special chars in name field', () => {
    let dynamicEmail = Guid.raw() + '@example.com'
    cy.request({
      method: 'POST',
      url: registerEndpoint,
      body: {
        name: 'tester!@#$%^&*()-_=+/.><~`  ',
        email: dynamicEmail,
        password: '12345678',
      },
    }).then(response => {
      expect(response.status).to.equal(200)
    })
  })

  it('User Registration - Special chars in password field', () => {
    let dynamicEmail = Guid.raw() + '@example.com'
    cy.request({
      method: 'POST',
      url: registerEndpoint,
      body: {
        name: 'testerspecialchars',
        email: dynamicEmail,
        password: '123456!@#$%^&*()-_=+/.><~`  ',
      },
    }).then(response => {
      expect(response.status).to.equal(200)
    })
  })

  it('User Registration - Registration with an already exists email', () => {
    cy.request({
      method: 'POST',
      url: registerEndpoint,
      failOnStatusCode: false,
      body: {
        name: 'tester',
        email: 'tester@example.com',
        password: '12345678',
      },
    }).then(response => {
      expect(response.status).to.equal(400)
      expect(response.body).to.equal('Email already exists')
    })
  })
})
```

This test suite includes a set of negative test cases for the user registration route using Cypress.io. These tests focus on verifying that the API can handle and respond to various unfavorable or edge-case scenarios during user registration.

These negative test cases help ensure that the registration API can properly handle different edge cases and return the appropriate responses for various input scenarios.

![register-spec](https://user-images.githubusercontent.com/83350680/191088312-76a48269-703e-41cf-aee7-5be1963670bb.jpeg)

Let's finish with the login endpoint!

Same steps, starting with some sanity tests first.

```javascript
const loginEndpoint = 'http://localhost:3000/api/user/login'

describe('User Login - Sanity', () => {
  it('User Login - Status Code 200', () => {
    cy.request({
      method: 'POST',
      url: loginEndpoint,
      body: {
        email: 'static@test.io',
        password: 'simplepass',
      },
    }).then(response => {
      expect(response.status).to.equal(200)
    })
  })

  it('User Login - Response', () => {
    cy.request({
      method: 'POST',
      url: loginEndpoint,
      body: {
        email: 'static@test.io',
        password: 'simplepass',
      },
    }).then(response => {
      expect(response.body).to.equal('Logged in successfully')
    })
  })

  it('User Login - Wrong email', () => {
    cy.request({
      method: 'POST',
      url: loginEndpoint,
      failOnStatusCode: false,
      body: {
        email: 'static1@test.io',
        password: 'simplepass',
      },
    }).then(response => {
      expect(response.status).to.equal(400)
      expect(response.body).to.equal('Email not found')
    })
  })

  it('User Login - Wrong password', () => {
    cy.request({
      method: 'POST',
      url: loginEndpoint,
      failOnStatusCode: false,
      body: {
        email: 'static@test.io',
        password: 'simplepass1',
      },
    }).then(response => {
      expect(response.status).to.equal(401)
      expect(response.body).to.equal('Invalid password')
    })
  })
})
```

These tests focusing on validating the status code and response content of the API for various login scenarios.
These sanity tests help ensure that the login API can properly handle different scenarios and return the appropriate responses for valid and invalid login attempts.

Then moving on to some edge cases and negative cases.

```javascript
describe('User Login - Error Cases', () => {
  it('User Login - Missing email field', () => {
    cy.request({
      method: 'POST',
      url: loginEndpoint,
      failOnStatusCode: false,
      body: {
        password: 'simplepass',
      },
    }).then(response => {
      expect(response.status).to.equal(400)
      expect(response.body).to.equal('"email" is required')
    })
  })

  it('User Login - Missing password field', () => {
    cy.request({
      method: 'POST',
      url: loginEndpoint,
      failOnStatusCode: false,
      body: {
        email: 'static@test.io',
      },
    }).then(response => {
      expect(response.status).to.equal(400)
      expect(response.body).to.equal('"password" is required')
    })
  })
})
```

These tests focusing on verifying that the API can handle and respond to various unfavorable or edge-case scenarios during user login.
These error and edge case tests help ensure that the login API can properly handle different scenarios and return the appropriate responses for various input situations.

![login-spec](https://user-images.githubusercontent.com/83350680/191088279-6bb19b69-6bf0-4354-99c4-08ece316fa43.jpeg)

Not too bad, right?

Don't forget to run the test by running `npm test`!

![test-summary](https://user-images.githubusercontent.com/83350680/191088369-19a49e8a-a24b-4fc0-8142-6b7560f2601e.jpeg)

The source code of the simple express application and the tests, can be found here - [https://github.com/Kazaz-Or/APITestingUsingCypress](https://github.com/Kazaz-Or/automation-projects/tree/develop/APITestingUsingCypress)


Most common use cases of Cypress.io are UI & Visual testing. But, employing Cypress for testing REST APIs can also be quite efficient.

Testing REST API with Cypress is easy


In the realm of JavaScript, developers have a many different sets of data structures at their disposal. One such data structure, is the Map object, which offers significant advantages over other commonly used data structures, such as Arrays and Objects. In this article, I will share the benefits I discovered while using Map in JavaScript and provide comparisons to other data types like arrays and objects.

P.S:
I'm far from an expert so if you're interested in an article that cover this subject much more thoroughly, I recommend this amazing builder.io blog post - [Use Maps More and Objects Less](https://www.builder.io/blog/maps).

So let's begin.

**_Key-Value Pairs and Unique Keys_**
One of the most significant advantages of using Map is its ability to store key-value pairs. Unlike arrays, which only use numeric indices (indexes), Map objects allows to use any data type as a key, including objects and functions. Additionally, Map ensures that each key is unique, simplifying data organization and retrieval.

**Arrays:** Numeric indices only, leading to limitations in organizing data.

**Objects:** Can use any data type as keys but do not guarantee unique keys.

**Maps:** Any data type as keys, offering flexibility and unique keys for better organization.

```javascript
// Arrays
const array = ['value1', 'value2', 'value3']
// Access element using numeric index
console.log(array[0]) // Output: 'value1'

// Objects
const object = {
  key1: 'value1',
  key2: 'value2',
  key3: 'value3',
}
// Access element using any data type as key (but not guaranteed unique)
console.log(object['key1']) // Output: 'value1'
object['key1'] = 'newValue1'
console.log(object['key1']) // Output: 'newValue1'

// Maps
const map = new Map()
const objKey = { id: 1 }
const funcKey = function () {
  return 'hello'
}
map.set(objKey, 'value1')
map.set(funcKey, 'value2')
map.set('key3', 'value3')

// Access element using any data type as key (unique keys)
console.log(map.get(objKey)) // Output: 'value1'
console.log(map.get(funcKey)) // Output: 'value2'
```

**_Iteration and Order Preservation_**
Another notable advantage of using Map is its built-in iteration capability, which preserves the insertion order of elements. This feature is particularly useful when developers need to maintain the order of elements while performing operations or iterating over the data.

**Arrays:** Preserves order, but lacks built-in iteration methods for key-value pairs.

**Objects:** Order not guaranteed, and lacks built-in iteration methods for key-value pairs.

**Maps:** Preserves order and provides built-in iteration methods for key-value pairs.

```javascript
// Arrays
const array = ['value1', 'value2', 'value3']
array.forEach((value, index) => {
  console.log(index, value)
})

// Objects
const object = {
  key1: 'value1',
  key2: 'value2',
  key3: 'value3',
}
for (const key in object) {
  if (object.hasOwnProperty(key)) {
    console.log(key, object[key])
  }
}

// Maps
const map = new Map()
map.set('key1', 'value1')
map.set('key2', 'value2')
map.set('key3', 'value3')
map.forEach((value, key) => {
  console.log(key, value)
})
```

**_Efficient Additions and Deletions_**
When comparing arrays, objects, and maps, it is important to consider the differences in how they handle additions and deletions. Maps are specifically designed for efficient manipulation of key-value pairs, making them more suitable for situations where frequent updates are required.

**Arrays:** When adding or deleting elements in arrays, the length of the array needs to be adjusted. Deleting an element from an array using `splice()` leaves no gaps, but it requires re-indexing the remaining elements, leading to performance issues in large data sets. Additionally, the length property of an array will update accordingly when elements are added or removed.

Keep in mind that if your'e using the `delete` keyword (common root cause for bugs) - it removes the element, but the length of the array remains the same. The deleted element's position will be `undefined`.

**Objects:** Deleting properties from objects does not require re-indexing or updating the length, but it can be slower with large objects. Objects also do not have a built-in property for tracking the number of properties, making it harder to manage the size of the object.

**Maps:** Maps are designed for efficient addition and deletion of key-value pairs. They have a built-in size property for tracking the number of elements, making it easier to manage the size of the Map. The performance of maps is optimized for frequent additions and deletions, providing better performance in scenarios that require frequent updates.

```javascript
// Arrays
const array = ['value1', 'value2', 'value3']

// Adding an element
array.push('value4')

// Deleting an element
const indexToDelete = 1
array.splice(indexToDelete, 1)

// Deleting an element using the delete keyword
delete array[1] // Removes the element at index 1

console.log(array) // Output: ["value1", undefined, "value3"]
console.log(array.length) // Output: 3

// Objects
const object = {
  key1: 'value1',
  key2: 'value2',
  key3: 'value3',
}

// Adding a property
object.key4 = 'value4'

// Deleting a property
delete object.key2

// Maps
const map = new Map()
map.set('key1', 'value1')
map.set('key2', 'value2')
map.set('key3', 'value3')

// Adding a key-value pair
map.set('key4', 'value4')

// Deleting a key-value pair
map.delete('key2')
```

**_Enhanced Performance_**
When it comes to performance, Map outshines both arrays and objects in specific use cases, such as frequent additions and deletions of key-value pairs. Maps are optimized for these operations, providing faster performance than arrays and objects under such circumstances.

**Arrays:** Slower performance when adding or deleting elements, especially in large data sets.

**Objects:** Slower performance when adding or deleting properties, particularly with large objects.

**Maps:** Optimized for faster performance during frequent additions and deletions.

As for the examples - Using `console.time()` and `console.timeEnd()` to measure the time taken for performing the same set of actions on Arrays, Objects, and Maps may not show significant differences in small examples. However, I'll provide an example with these methods for a general idea. Note that the difference in performance will be more evident with larger data sets or more complex operations.

```javascript
// Arrays
const array = ['value1', 'value2', 'value3']
console.time('ArrayOperations')
array.push('value4')
array.splice(1, 1)
console.timeEnd('ArrayOperations') // Output: ArrayOperations: 808.588ms

// Objects
const object = {
  key1: 'value1',
  key2: 'value2',
  key3: 'value3',
}
console.time('ObjectOperations')
object.key4 = 'value4'
delete object.key2
console.timeEnd('ObjectOperations') // Output: ObjectOperations: 799.399ms

// Maps
const map = new Map()
map.set('key1', 'value1')
map.set('key2', 'value2')
map.set('key3', 'value3')
console.time('MapOperations')
map.set('key4', 'value4')
map.delete('key2')
console.timeEnd('MapOperations') // Output: MapOperations: 608.085ms
```

**_Efficient Size Retrieval_**
When working with different data structures, it's important to know how easily and efficiently you can retrieve their sizes. Maps offer a simple and efficient way to do this compared to arrays and objects.

**Arrays:** Arrays have a built-in length property that provides the count of elements. While this is convenient, it doesn't offer the key-value pair structure that some use cases may require.

**Objects:** Objects do not have a built-in property to count their elements. To retrieve the count, you must loop through properties or use methods like Object.keys() or Object.getOwnPropertyNames(), which can be cumbersome and less efficient.

**Maps:** Maps provide a built-in size property, making it easy and efficient to determine the number of key-value pairs in the Map. This offers an advantage in use cases that require quick access to the element count.

```javascript
// Arrays
const array = ['value1', 'value2', 'value3']
console.log(array.length) // Output: 3

//Objects
const object = {
  key1: 'value1',
  key2: 'value2',
  key3: 'value3',
}
console.log(Object.keys(object).length) // Output: 3

//Maps
const map = new Map()
map.set('key1', 'value1')
map.set('key2', 'value2')
map.set('key3', 'value3')
console.log(map.size) // Output: 3
```

There are many more advantages which i won't get into such as memory management and etc.

In conclusion, Map objects provide several advantages over arrays and objects in JavaScript.
They offer flexibility with key-value pairs, preserve order during iteration, optimize performance for frequent additions and deletions, simplify element counting, and support garbage collection using WeakMaps. By understanding the differences and benefits of each data structure, developers can make informed decisions when choosing the best option for their specific use cases. Maps are a powerful addition to the JavaScript toolkit, offering enhanced functionality and performance in various scenarios where arrays and objects may fall short.


The advantages of using Map in JavaScript over other Data Types

You Should Really Use Map When Possible


I'll start with a full disclosure - Up until now, I have only written unit tests using Jest. However, at my current job, I had the opportunity to work on a small project that allowed me to choose a new testing library.

After some research, I decided to go with Mocha as a test runner and Chai for assertions. Then I reached the fun part - Mocking and Spying.
The most obvious choice was Sinon, which works great as a spy (for example, if you want to know whether a certain log was printed). However, when it came to Mocking (or Stubbing), it wasn't easy at all.

If you're interested - I found this article back then and I found it to be quite true ([why is it so hard to test in NodeJS](https://www.vinnie.work/blog/2021-09-18-why-so-hard-testing-with-es6-imports))

After struggling with Sinon, I turned to the Discord Node.js community with a specific question:

![discordquestion](/images/discord-node-test.png)

The first response was a link to the [rewire](https://github.com/jhnns/rewire) repository. I must say, once I started using it, I couldn't stop. It made mocking incredibly easy.

To install it simply run:

```
npm install rewire
```

import it:

```js
const rewire = require('rewire')
```

To initialize it, you need to "rewire" the module that contains the functions, methods, or variables you'd like to mock.

```js
const mockedIndex = rewire('../../index')
```

So let's look at some examples:

I'll start with the original question I raised in the Node Discord server.
Here's my original function (just for the sake of the example):

```js
async function updatePolicy(project, policy, file) {
  return Promise.allSettled(Object.entries(file).map(([status]) => {
    try {
      if (!countryRules[country]) {
        return Promise.resolve();
      }
      if (statusDisable(status))
        console.log('disable');
      else if (statusEnable(status))
        console.log('enable');
        [...]
}
```

I wanted a simple test case to check that the correct function is called given the right arguments.
Since I had many test cases like these, I created a more "generic" function that receives the function I'd like to test as an argument.

```js
// rewire the module
const lib = rewire('../../index')

// generic function

const checkFunctionCall = (functionName, done, file) => {
  lib.__set__(`${functionName}IsCalled`, false) // setting the function under test to isCalled false
  lib.__set__(functionName, () => {
    // function under test is called
    lib.__set__(`${functionName}IsCalled`, true) // changing the isCalled to true in this case.
  })
  lib.updatePolicy(project, policy, file) // Calling the function that eventually calls the function i'd like to assert on
  assert.equal(lib.__get__(`${functionName}IsCalled`), true) // asserting that isCalled is true
  done()
}

// test case

it('statusEnable function called', done => {
  let file = 'example argument'

  checkFunctionCall('statusEnable', done, file)
})
```

Doesn't seem so complicated, right?
Moving on to mocking of an async function that should return resolved promise. Let's say this is the original function:

```js
async function persistCatalogs(bucketName, catalogs) {
  const catalogBucket = storageClient.bucket(bucketName)
  return new Promise(async (resolve, reject) => {
    for (const chunk of keyChunks) {
      await Promise.all(
        chunk.map(async catalog =>
          uploadCatalog(catalogBucket, cacheTtl, catalog, catalogs[catalog])
        )
      )
    }
    resolve()
  }).then(() => logger.info('Catalog uploaded!'))
}
```

I'd like to test that given a specific argument, the `uploadCatalog` function was called 12 times.

```js
// stubbed function that will be called when mocking the uploadCatalog function
function uploadCatalogStub() {
  return Promise.resolve('Mocked result')
}
//test case
it('should upload each catalog in chunks', async () => {
  lib.__set__('uploadCatalog', uploadCatalogStub) // rewire will set uploadCatalogStub once uploadCatalog is called
  await lib.persistCatalogs(bucketName, catalogs) // Original function called
  expect(uploadCatalogStub.callCount).to.equal(12) // assertion
})
```

Moving on the mocking a global variable that eventually will be used in a function.

This is the function i'd like to test:

```js
function addEventToCatalog(rawEvent, catalog) {
  rawEvent.countryAvailability.forEach(c => {
    if (COUNTRIES_LIST.includes(c))
      catalog[c].push(event);
    else
      logger.warn(`Unsupported country ${c} on event ${event.assetId}, skipping for catalog`);
  });
```

Now `COUNTRIES_LIST` variable is a global variable, which it's data in it might effect the result of the test. So let's mock it:

```js
lib.__set__('COUNTRIES_LIST', structuredClone(countryCodesData)) //COUNTRIES_LIST is a global variable, here it'll return a clone of another data i chose.
```

and call the tested function is test as usual:

```js
it('should add event to US catalog if countryAvailability includes US', () => {
  lib.addEventToCatalog(rawEvent, catalog)

  expect(catalog.US).to.have.lengthOf(1) // assertion
})
```

In conclusion, `rewire` proved to be the simplest mocking library I've had the opportunity to use in Node.js projects.
Ultimately, pairing it with a dynamic test runner like Mocha made for an easy choice compared to other libraries.

As a result, I ended up replacing all other mocks, such as Sinon Stubbing, with Rewire and haven't looked back since.


Unit testing in Node.js can be challenging. After trying various libraries, I found Rewire to be the most practical for testing purposes

JavaScript Articles

All JavaScript Articles