
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


I absolutely love using pytest as my go-to testing tool whenever I'm working on a Python project. Among its many features, pytest's parametrization is a standout and has been crucial in simplifying my test cases and maximizing code reusability instead of duplicating tests.
What's more, if it's not clear, parameterized tests are being presented as different tests on each test execution and report.

I have been using it ever since I started using pytest for many different test types, such as unit tests, end-to-end tests, and integration tests.

Let's take a look at some real examples (although I had to make them a little bit more generic) of how to use pytest parametrization.

__Basic Parametrization__

The most straightforward use case is to feed multiple inputs to a single test function. This is useful for testing different edge cases or multiple data points without writing separate test cases.

In the example below we wrote a test function that asserts on the length of a string, while with parametrization we can test multiple strings with a single test function.
We provide test input (for example "hello") and the expected result (in this case 5).

```python
import pytest

@pytest.mark.parametrize("input_string, expected_length", [
    ("hello", 5),
    ("world", 5),
    ("pytest", 6)
])
def test_string_length(input_string, expected_length):
    assert len(input_string) == expected_length
```

__Indirect Parametrization__

With indirect, rather than passing the value directly to the test function, pytest will treat the given input as a fixture name. This allows us to use the fixture's logic to transform or process the input value before passing it to the test. Here, each number is doubled using a fixture before being tested.

```python
import pytest

@pytest.mark.parametrize("input, expected", [
    (2, 4),
    (3, 6),
    (4, 8)
], indirect=["input"], ids=["double-2", "double-3", "double-4"])
def test_double_number(input, expected):
    assert double(input) == expected

@pytest.fixture
def double(input):
    return input * 2
```

__Custom ID for Test Cases__

Sometimes it's beneficial to have custom names for our tests, especially when the default names become unclear or too lengthy. The ids parameter lets us define custom names for our tests. In this example, we use custom IDs to quickly identify tests for even and odd numbers using the `ids` argument that expects a list.


```python
import pytest


@pytest.mark.parametrize("number", [2, 3, 4, 5, 6],
                         ids=["ev-2", "odd-3", "ev-4", "odd-5", "ev-6"])
def test_even_numbers(number):
    is_even = number % 2 == 0
    if "ev" in pytest.current_test().name:
        assert is_even
    else:
        assert not is_even
```

__Parametrization with Multiple Arguments__

Here we demonstrate how to parameterize a test with multiple input arguments. We're testing the addition of two numbers. This is a powerful feature when we want to test a function with various combinations of inputs.

```python
import pytest


@pytest.mark.parametrize("a, b, expected_sum", [
    (1, 2, 3),
    (3, 3, 6),
    (5, 5, 10)
])
def test_addition(a, b, expected_sum):
    assert a + b == expected_sum
```

__Utilizing Parametrization in Asynchronous Tests__

With pytest-asyncio plugin (which is kind of standard these days), we can also parameterize asynchronous tests. In this example, we test an asynchronous function that returns a string after a built-in delay just for the sake of the example.

```python
import pytest
import asyncio

@pytest.mark.parametrize("input_str", ["hello", "world", "pytest"],
                         ids=["hello-async", "world-async", "pytest-async"])
@pytest.mark.asyncio
async def test_string_return_async(input_str):
    returned_str = await async_string_return(input_str)
    assert returned_str == input_str

async def async_string_return(s):
    await asyncio.sleep(0.1)
    return s
```

__Parametrization with Dynamic Fixtures__

The following test demonstrates a more complex usage of pytest's parametrization. This is especially the case when you have a dynamic fixture (like `dynamic_execution_payload`) which depends on the parameter passed (`path_arg` in this example).

```python
import pytest


BASE_URL = "http://example.com/api"


@pytest.fixture(scope="function")
def payload_for_execution(file_path):
    return {
        'repo': "demo-repo",
        'ref': "demo-branch",
        "paths": [file_path]
    }


@pytest.mark.parametrize('file_path', [
    'mock/testDir/file4.js',
    'mock/testDir/file3.js',
    'mock/testDir/file1.js',
    'mock/testDir/file2.js'
])
def test_file_processing_with_dynamic_payload(file_path, payload_for_execution):
    execution = requests.post(url=f"{BASE_URL}/startExecution",
                              headers={"Content-Type": "application/json"},
                              json=payload_for_execution)
    execution_id = execution.json()['executionId']
    
    response = requests.get(url=f"{BASE_URL}/getExecution/{execution_id}",
                            headers={"Content-Type": "application/json"})
    response_json = response.json()
    
    assert 'result' in response_json, "Response JSON does not have the 'result' key"
```

First we specified different file paths as inputs for the test function. For each of these paths.
With it we utilize the fixture `payload_for_execution` that generates a payload dynamically based on the `file_path` given and this payload is then used in our test. This demonstrates how you can use the parameters of your test in your fixtures, making your tests more dynamic and flexible.

Within the test, an HTTP POST request is made to presumably start some kind of processing for the file specified in the payload. This request returns an execution ID. A subsequent GET request fetches the result of this execution. Finally, assertions are performed on this result.

__Parametrization with Using Dates__

Dates in every language can be a true pain, therefore its important we tests them thoroughly.

```python
import pytest

from datetime import datetime, timedelta


@pytest.mark.parametrize(
    "input_date, expected_query",
    [
        (datetime(2023, 3, 15), "?start=2023-03-01&end=2023-04-01&category=premium"),
        (datetime(2023, 12, 31), "?start=2023-12-01&end=2024-01-01&category=premium"),
        (datetime(2023, 1, 1), "?start=2023-01-01&end=2023-02-01&category=premium"),
        (datetime(2023, 2, 28), "?start=2023-02-01&end=2023-03-01&category=premium"),
    ],
    ids=["mid-March", "end-of-year", "start-of-year", "end-of-February"]
)
def test_generate_query_based_on_date(mocker, input_date, expected_query):
    mocker.patch("module_under_test.datetime", MockDateTime)
    MockDateTime.now = mocker.Mock(return_value=input_date)
    assert generate_query_for_service(category='premium') == expected_query

def generate_query_for_service(category):
    now = datetime.now()
    start_of_month = now.replace(day=1)
    end_of_month = (start_of_month + timedelta(days=32)).replace(day=1)
    return f"?start={start_of_month.strftime('%Y-%m-%d')}&end={end_of_month.strftime('%Y-%m-%d')}&category={category}"
```

First we provide different datetime objects as inputs. For each datetime, there's a corresponding expected output. This is a classic example of table-driven testing. But in many scenarios, functions might fetch the current date and time using something like `datetime.now()` which can become tricky for testing, thats why you want to control what "now" means so you can predict the output. The `mocker.patch` (using pytest-mock plugin) line mocks the return value of `datetime.now()` to be the input date, allowing for predictable and testable behavior.

The hypothetical function `generate_query_for_service` is responsible for generating a query based on the current date and a given category. It's logic is simplified for this demonstration.

With this structure, you're dynamically testing the function with multiple dates, ensuring it works across various boundary conditions like month ends, year starts, etc.

__Parametrization for Testing Common Web Components__

There are some cases where you have components that are used in multiple places in your application. For example, you might have a navigation bar component that displays on all of your website pages. So you might want to test that component in isolation, but also test it in the context of different pages, this can be done easily with parametrization.

```python
import pytest


test_data = [
    ('https://www.kazis.dev/', "homepage"),
    ('https://www.kazis.dev/about', "about page"),
    ('https://www.kazis.dev/blogs', "blogs page"),
    ('https://www.kazis.dev/blogs/python-type-checking', "blog page")
]

@pytest.mark.parametrize("test_url, test_id", test_data, ids=[item[1] for item in test_data])
def test_logo_element_exists(sync_page, test_url, test_id):
    home_page = NavBar(sync_page)
    home_page.open(test_url)
    link = sync_page.locator('role=link >> text=Kazis Dev Blog Kazi\'s Dev Blog')
    assert link, "Link not found."
```

So in this example we're using Playwright test framework, but the same concept can be applied to any other framework. We have a list of tuples, each tuple contains a URL and a test ID. The test ID is used to identify the test in the report and display it in every test execution.
We then use the `parametrize` decorator to pass the URL and test ID to the test function. We also use the `ids` argument to specify the test ID for each test case.

And in the test function itself we assert that the logo element exists on each page that we're providing as an input. This test will run for each URL in the list and it's a classic example how we can test simple functionality of a web component that doesn't change on different pages.


To conclude,
Pytest parametrization is a powerful feature that reduces redundancy, improves test clarity, and enhances the reusability of test code. These are just a few examples showcasing its capabilities. Using parametrization, you can write more concise and robust tests, and that's without mentioning other out of the box plugins which support pytest.


I absolutely love using pytest as my go-to testing tool whenever i'm working on a Python project. Pytest Parametrization is one of reasons why.

Powerful Pytest Parametrization


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


When it comes to testing in Python, pytest stands out as an excellent framework with its rich feature-set that includes detailed info on failing assert statements, auto-discovery of test modules, and advanced fixture management. While working on unit testing for one of our python services at work I wanted to test some scenarios that involves some more critical logging for debugging at real time. 

Taking a look at [pytest official docs](https://docs.pytest.org/en/7.1.x/how-to/logging.html) I got to know the `caplog` fixture. I had many cases before where I actually found better solutions from built-in fixtures, but this time I was amazed by how easy it was to use and how much it can do. And it's safe to say I never looked back when it's comes to logging capturing in pytest.

__So what is caplog?__

In pytest, caplog is a fixture provided by pytest, which captures log messages emitted by the logging module. This allows you to validate that your application is logging the right messages or to debug a test by capturing and examining the log output and the log level.

Let's start with a concrete test case to illustrate caplog's usage:

```python
import pytest
import logging

def test_logging(caplog):
    logging.getLogger().info("Test logging")
    assert "Test logging" in caplog.text
```

In the test above, we import the caplog fixture from pytest. We then log an info message and assert that the message is present in the captured log text.


While caplog is great for checking that a specific log message was output, it can do a lot more. You can use it to validate the level of logging messages, check the logger that issued them, and even change the log level for the duration of the test.

Here's an example where we're doing more advanced checks:

```python
def test_logging_advanced(caplog):
    caplog.set_level(logging.INFO)
    logger = logging.getLogger("TestLogger")
    logger.warning("This is a warning")

    assert "This is a warning" in caplog.text
    assert caplog.records[0].levelname == "WARNING"
    assert caplog.records[0].name == "TestLogger"
```

In the example above, we first set the logging level to INFO, then log a warning message. Afterwards, we assert that the message is in the captured log, but also that the level of the message is WARNING and that it came from the logger "TestLogger".

You can also assert messages from specific loggers:

```python
def test_logging_from_specific_logger(caplog):
    logger = logging.getLogger('MyLogger')
    logger.error("An error message")
    assert "An error message" in caplog.text
    assert caplog.records[0].name == "MyLogger"
```

In this test, we create a logger with the name 'MyLogger', emit an error message, and then confirm that the message was logged by that specific logger.

In some cases, you may want to clear the messages captured by caplog. This is particularly useful in parameterized tests or when a single test function is checking multiple scenarios.


```python
def test_clearing_log_messages(caplog):
    logger = logging.getLogger()
    logger.info("First message")
    caplog.clear()

    logger.info("Second message")
    assert "First message" not in caplog.text
    assert "Second message" in caplog.text
```

Here, after logging the "First message", we clear the caplog. Then we log the "Second message" and check that the first message is not in the captured log, while the second message is.

There are some cases where the tested function or method may produce multiple logs. In such cases, you can use the caplog.records list to check the log messages. This list contains all the log records captured by caplog, and you can use it to check the log messages, levels, and loggers.

```python
import pytest
import logging

def function_that_logs():
    logger = logging.getLogger()
    logger.warning("This is a warning message")
    logger.error("An error has occurred!")
    logger.info("Completed operation successfully.")

def test_log_capturing(caplog):
    function_that_logs()
    log_messages = [record.message for record in caplog.records]
    assert "This is a warning message" in log_messages
    assert "An error has occurred!" in log_messages
    assert "Completed operation successfully." in log_messages
```
In this example, the function_that_logs() generates multiple log messages of different levels: WARNING, ERROR, and INFO.

Our test test_log_capturing() invokes function_that_logs(), captures the log messages into a list, and then verifies each of the expected log messages is present in the captured logs.

Note that caplog by default captures log messages of WARNING level or higher. So if you need to capture lower-level messages (e.g. INFO or DEBUG), you should set the logging level in caplog to a lower value before the function call.

It's important to note, that such tests as the example above, you are asserting that the messages are present somewhere in the log, regardless of their position. This is done by checking that the expected message is in the list of log messages, which will return True if the expected message is found anywhere in the list.

If you want to assert on the order of the log messages, then you would need to check the messages based on their index in the log_messages list. For example, if you want to check that the first logged message is "This is a warning message", you could do:

```python
assert log_messages[0] == "This is a warning message"
```

This will only pass if "This is a warning message" is the first message in the log. However, remember that relying on the order of log messages can make your test more brittle, as changes to the order of logging in the code would cause the test to fail. In general, it's better to check that the expected messages are present somewhere in the log, unless the order is particularly important.

That's about it, easy, right?
By using pytest's caplog fixture, you can create robust tests that not only verify your application's behavior, but also confirm it's producing the right log messages. This can be invaluable when diagnosing issues in production, as it ensures your logging is accurate.


Pytest's built-in caplog fixture to capture log messages is nothing but amazing. Capture logs for unit testing can't get easier

Capturing Logs with Pytest Can't Be Easier


I'll start with a confession - I'm fairly new to Typescript. Still learning how to work with it. I'm loving it so far, but, I have struggled so badly when it came to testing while using the notorious combination of Node, TypeScript & ES Module.
Maybe it's because i'm still learning TS, but I really appreciate tools which requires minimal to zero configuration. I know that's how it works with most tools in the JS/TS echo-system, but that's exactly what Vitest is.

So far, I could work my way with unit testing mostly using Jest, but it took me some time to make things up and running.

So to configure Jest correctly on my project, I had to add and install the following packages:

- jest
- ts-jest   
- @types/jest

Then I had to setup a `jest.config.js` file with the following content:

```js
import type { Config } from '@jest/types'

const baseDir = 'some/path'

const config: Config.InitialOptions = {
  preset: 'ts-jest',
  testEnvironment: 'node',
  verbose: true,
}

export default config;
```

If we are going with this minimal example, let's take some Utils class example:

```typescript
export class StringUtils {
    public toUpperCase(arg: string) {
        if (!arg) {
            throw new Error("Invalid Argument");
        }
        return toUpperCase(arg);
    }
}

export function toUpperCase(arg: string) {
    return arg.toUpperCase();
}

export type stringInfo = {
    lowerCase: string,
    upperCase: string,
    characters: string[],
    length: number,
    extraInfo: Object | undefined
}

export function getStringInfo(arg: string): stringInfo {
    return {
        lowerCase: arg.toLowerCase(),
        upperCase: arg.toUpperCase(),
        characters: Array.from(arg),
        length: arg.length,
        extraInfo: {}
    }
}
```

This TypeScript code defines a class StringUtils with a method toUpperCase, which converts a string to uppercase, throwing an error for invalid arguments. The standalone function toUpperCase is also doing the same thing, converting the passed string to uppercase. The getStringInfo function takes a string as input and returns an object containing information about that string, such as its lowercase and uppercase forms, an array of its characters, its length, and an extra information object.

Let's take a look at some unit tests written with Jest:

```typescript
import { StringUtils, getStringInfo, toUpperCase } from "./Utils"


describe('utils test suite', () => {

    test.each([
        {input: 'test', expected: 'TEST'},
        {input: 'TEST', expected: 'TEST'},
        {input: 'test1$&*#()^41', expected: 'TEST1$&*#()^41'}
    ])('$input to UpperCase should return $expected', ({input, expected}) => {
        const result = toUpperCase(input);

        expect(result).toBe(expected);
    });

    test('should return info for valid string', () => {
        const result = getStringInfo('My-String');

        expect(result.extraInfo).toEqual({});
        expect(result.lowerCase).toBe('my-string');
        expect(result.length).toBe(9);

        expect(result.characters).toStrictEqual(["M", "y", "-", "S", "t", "r", "i", "n", "g"]);
        expect(result.characters).toHaveLength(9);
        expect(result.characters).toContain<string>('-');
    });

});


describe('StringUtils class', ()=> {
    let sut: StringUtils;

    beforeEach(()=>{
        sut = new StringUtils();
    });

    test('Sanity - valid string', () => {
        const result = sut.toUpperCase('abc');
        
        expect(result).toBe('ABC');
    });

    test('Should throw error on invalid argument (empty string) - function', () => {
        function expectError() {
            const result = sut.toUpperCase('');
        };
        
        expect(expectError).toThrow();
        expect(expectError).toThrowError('Invalid Argument');
    });

    test('Should throw error on invalid argument (empty string) - arrow function', () => {
        expect(() => {
            sut.toUpperCase('')
        }).toThrowError('Invalid Argument');
    });

    test('Should throw error on invalid argument (empty string) - try catch block (workaround)', (done) => {
        try {
            sut.toUpperCase('');
            done('GetStringInfo should throw error for invalid arg');
        } catch (error) {
            expect(error).toBeInstanceOf(Error);
            expect(error).toHaveProperty('message', 'Invalid Argument');
            done();
        }
    });

});
```

What if I want to switch to Vitest Now? Well, I'll have to install the following package:

- vitest

Yep, that's it.

A project using TS & ES Module will work out of the box with Vitest. No need to configure anything.

Let's take a look at the same tests written with Vitest:

```typescript
import { test, describe, expect, beforeEach } from 'vitest'

import { StringUtils, getStringInfo, toUpperCase } from "./Utils"


describe('utils test suite', () => {

    test.each([
        {input: 'test', expected: 'TEST'},
        {input: 'TEST', expected: 'TEST'},
        {input: 'test1$&*#()^41', expected: 'TEST1$&*#()^41'}
    ])('$input to UpperCase should return $expected', ({input, expected}) => {
        const result = toUpperCase(input);

        expect(result).toBe(expected);
    });

    test('should return info for valid string', () => {
        const result = getStringInfo('My-String');

        expect(result.extraInfo).toEqual({});
        expect(result.lowerCase).toBe('my-string');
        expect(result.length).toBe(9);

        expect(result.characters).toStrictEqual(["M", "y", "-", "S", "t", "r", "i", "n", "g"]);
        expect(result.characters).toHaveLength(9);
        expect(result.characters).toContain<string>('-');
    });

});


describe('StringUtils class', ()=> {
    let sut: StringUtils;

    beforeEach(()=>{
        sut = new StringUtils();
    });

    test('Sanity - valid string', () => {
        const result = sut.toUpperCase('abc');
        
        expect(result).toBe('ABC');
    });

    test('Should throw error on invalid argument (empty string) - function', () => {
        function expectError() {
            const result = sut.toUpperCase('');
        };
        
        expect(expectError).toThrow();
        expect(expectError).toThrowError('Invalid Argument');
    });

    test('Should throw error on invalid argument (empty string) - arrow function', () => {
        expect(() => {
            sut.toUpperCase('')
        }).toThrowError('Invalid Argument');
    });

    test('Should throw error on invalid argument (empty string)', async () => {
        let error;
        try {
            sut.toUpperCase('');
        } catch (e) {
            error = e;
        }
        expect(error).toBeInstanceOf(Error);
        expect(error).toHaveProperty('message', 'Invalid Argument');
    })

});
```

The code may look quite similar to Jest because Vitest intelligently adopts the Jest APIs, thereby reducing the learning curve for those transitioning from Jest. This is one of the many reasons why it feels so familiar and yet so refreshingly simple.

To wrap things up, transitioning from Jest to Vitest for a TypeScript project was a refreshing experience for me. With its familiar API and almost non-existent setup, Vitest feels like a game changer, especially for a newcomer to TypeScript like me. And of course, this is without mentioning other features a abilities of Vitest like:
Executing tests in parallel, running tests in watch mode, running tests in debug mode, it's much faster than Jest, and more.

If you're in a similar boat, I encourage you to give Vitest a shot.


I have struggled so badly when it came to testing while using the notorious combination of Node, TypeScript & ES Module. And then I found Vitest

I Wish I Knew Vitest When I Started My TypeScript Journey


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


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

Leverage Rewire for Unit Testing in Node.js


Explaining this article without divulging specific product details may be a challenge, but I'll attempt to simplify it. 
The product is an embedded device that streams video packets over IP via multiple network interfaces, such as Ethernet, WiFi, or modems, and then bonds (aka, [bonding](https://en.wikipedia.org/wiki/Bonding_protocol)) them on the server to produce clear video without artifacts.

The company's hardware team developed a new device with improved hardware peripherals to achieve certain objectives that the company's existing devices couldn't. The new device was highly anticipated, and time was of the essence. 

The new hardware architecture was based on something called PHY to PHY, which means the NIC of the board and the NIC of the video encoder were directly connected to each other, while the network interface was defined as VLAN to run a "keep-alive" traffic between the two.
This architecture was entirely different than what out other products were designed.

![PHY-TO-PHY](/images/phy-system-diagram.jpg)

This required some testing of course.

The test involved physically connecting the two [PCB's evaluation boards](https://www.tempoautomation.com/blog/pcb-evaluation-vs-development-board-what-is-the-difference/#:~:text=The%20evaluation%20board%20is%20used,pertinent%20components%20and%20connectors%20included) with Ethernet cable (RJ45) and generating UDP/TCP traffic between them while measuring the board's CPU usage, network capability and packet losses. 

The most common use case for the product was transmitting 100 Mbps of UDP packets from the encoder card to the main system board (IMX6 at the time). The IMX board was based on ARM architecture, and testing tools such as [iperf](https://iperf.fr/) and [mpstat](https://linux.die.net/man/1/mpstat) were added using the [Buildroot](https://buildroot.org/) toolchain to generate network traffic and monitor CPU usage. 

Since this was an internal network connected physically, packet loss was unexpected.

So I started testing using Iperf

From the encoder:

```
iperf –c 0.0.0.1 –I 1 -u –b 100m –t 500 -p 9000
```

On the IMX board (receiving board):

```
iperf -s -l 9000
```

![iperf-test](/images/iperf-test.png)


However, during a five-minute test, there were packet losses. In a video use case, video with losses results in artifacts, as shown in the example below. 

![videoartifacts](/images/videoartifacts.png)

Kinda bad right?

The company saved a significant amount of time by letting the QA team test the products on PCB evaluation boards before they were actually ready for testing, resulting in a new hardware revision. 
I don't know if your'e aware of the heavy cycle in terms on time and research it takes to fix an issue and make it ready for production in the hardware development world, but i'll give you a hint: It's far more than a software cycle.

The issue was eventually determined to be a hardware problem with the [clock signal](https://en.wikipedia.org/wiki/Clock_signal) on the board.


The test that saved my company a significant amount of time and effort - Using two PCB's, RJ45 cable, and the Iperf tool

All Blog Posts in the Testing Category