Attempting to test with Vitest

[khill-fbmc]

I decided to take a stab at getting your tests you wrote to work with Vitest since it is the new hotness.

I am getting close but getting this weird error, and since I don't know C++ I don't know what it means heh

[khill-fbmc]

Would I be correct to assume that it can only be imported / instantiated once?

I am trying to put this in a setup.mjs for vitest

import { gpiod } from "../index.mjs";

import { beforeAll } from "vitest";

beforeAll(() => {
    globalThis.gpiod = gpiod;
});

and this could be wrong, but I modded index.js => index.mjs

import os from 'node:os';
import bindings from 'bindings';

let libgpiod = { available: () => false };

// prevent module being loaded on anything other than Linux
if (os.type() === 'Linux') {
    // entry point
    try {
        libgpiod = bindings('node-libgpiod');

        libgpiod.Chip.prototype.getLine = (n) => {
            return new libgpiod.Line(this, n);
        };

        libgpiod.available = () => true;
    } catch (e) {
        console.error(e);
    }
}

export default libgpiod;
export const gpiod = libgpiod;

[khill-fbmc]

Importing it directly works...

and the suite passes (because I put .skip on the others)

[sombriks]

yes it might be related with #4 , at some point i need to go back on the C++ side and see how to solve that.

besides that, going CommonsJS or ES6 modules should not cause any major issue.

that would be a cool enhancement.

[khill-fbmc]

Getting closer!

import { gpiod } from "../index.mjs";

import { afterAll, beforeAll } from 'vitest';

beforeAll(() => {
    if (!globalThis.gpiod) {
        globalThis.gpiod = gpiod;
    }
});

afterAll(() => {
    delete globalThis.gpiod;
});

now works and

import { describe, it } from "vitest";

describe("libgpiod miscellaneous bindings", () => {
  it("should be available", async ({ expect }) => {
    expect(gpiod.available()).toBeTruthy();
  });

  it("should get libgpiod version", async ({ expect }) => {
    expect(gpiod.version()).toBe("1.6.2");
  });

  it("should get line instant value", async ({ expect }) => {
    const val = gpiod.getInstantLineValue(0, 17);
    expect(val).toBe(0);
  });

  it("should NOT get line instant value due wrong chip name", async ({ expect }) => {
    expect(() => {
      gpiod.getInstantLineValue("/dev/gpiochipZero", 17);
    }).toThrowError();
  });

  it("should blink line with instant value", async ({ expect }) => {
    let count = 7;
    const interval = setInterval(() => {
      gpiod.setInstantLineValue("/dev/gpiochip0", 17, count-- % 2);
      if (count == 0) {
        clearInterval(interval);
        return;
      }
    }, 70);
  });
});

passes :) and so does the chip tests.

It seems the initial error is part of the line tests...

[khill-fbmc]

I just pushed my work up

[sombriks]

this is nice ;-) i have a PR to enable it to run on every commit but as you can imagine we're limited by the lack of gpio pins on github runners 😅

anyway, please open a PR to the repo when you feel you get a time so we can offer this to everyone consuming this library.

[khill-fbmc]

made a workflow for testing... definitely will have to mock some things... 😄

[khill-fbmc]

How attached to the implementation of index.js are you? I'm running into the issue where I can't seem to get the os module to be mocked for the tests... os.type() === 'Linux' continues to be Darwin on my computer and can't import the module.

I was thinking maybe a factory function that returns the library so the os type check isn't a side effect of importing the module. Maybe have it throw and the user can handle the error?

[sombriks]

Hi @khill-fbmc !

This is one issue i could address along the 'testing mode' for the library.

In order to proper cover the library with tests, i will need to simulate gpiopins so it can be transparent for the javascript wrapper if we are in a real hardware of inside a github runner or something.

my findings so far point to use exactly what ligpiod itself uses to test: https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/tests/Makefile.am?h=v1.6.x

but we can also make use of some environment variables to override a few things, the operating system environment for instance.

we could create a set of prefixed environment variables to override our system checks, for example NODE_LIBGPIOD_OS_TYPE ; lib bootstrap would stilll performing the check, but the env var would take precedence and then we use that.

i plan to spare time this weekend to move forward to it, we can discuss good overrides for this situation and others

[sombriks]

still blocked by #24