Starchart: 1,2,3, Testing!

What is it?

After having created a test database for the Starchart project, I went on to working on tests for functions relate to Prisma API calls. (See PR)

We use Vitest for unit testing, which is very similar to Jest. A test suite looks something like this:

describe('createUser()', () => {
  let user: User;

  beforeAll(async () => {
    user = await createUser(
      'jsmith',
      'John Smith',
      'jsmith@myseneca.ca',
      'mycustomdomain-students'
    );
  });

  afterAll(async () => {
    await prisma.user.deleteMany().catch(() => {});
  });

  test('creates an User row with expected fields', async () => {
    expect(typeof user).toEqual('object');
    expect(user.username).toEqual('jsmith');
    expect(user.displayName).toEqual('John Smith');
    expect(user.email).toEqual('jsmith@myseneca.ca');
    expect(user.group).toEqual('mycustomdomain-students');
    expect(user.createdAt).not.toBe(null);
    expect(user.createdAt).toEqual(user.updatedAt);
    expect(user.deactivated).toBe(false);
  });

describe() is a test suite, which can include many related individual test()s. Both let you include a string to state what it's for, which will show up in a formatted display when you run tests.
beforeAll() is a block of code that executes before all tests of a suite is ran, which can be handy for setting up things, like creating an user for testing.
afterAll() is a block of code that executes after all tests of a suite is ran, which can be handy for clean-up, like deleting all existing user.

Each expect() is a condition that must be satisfied for a test to pass. The code is more or like like plain English language, such as expect(user.createdAt).not.toBe(null); really means expecting user.createdAt to not be null. You can find all the syntax in their documentation.

You can put code, such as variable declaration an function calls, under describe() or test(). It's just a matter of scope for what you want to do.

Assuming you already setup the tool properly (see official guide), you can run the tests via npx vitest. A result can look like this:

For seeing test coverage, run npx vitest run --coverage.

As you can see, it tells you how much of the files are covered by tests, in terms of statements, branching paths, functions, and lines. It also shows uncovered lines.

Why do this?

1. This provides repeatable and standardized tests that are easy to run and view. You don't have to risk making mistake or forgetting a test like when one does manual testing of codes. The tool also provide good feed back by showing you what tests fail and what files aren't covered.
2. It's also something that can be shared in a repository and make collaboration easier.
3. An interesting way to use this is to write out some tests and have them act as technical requirements that guide the development of code. Essentially, you write out tests that tells developers what the software is supposed to do, and the developers write codes that would satisfy these tests that act as technical requirements.