Add test framework, unit tests, and CI validation workflow #2

New Issue

2026-05-05T18:48:42Z

mahseiah_ai commented

2026-05-05 18:48:42 +00:00

Problem sheer

js-logging currently has no automated tests. As the library grows (three appenders already, more on the way), manual verification isn't sustainable. We need a test framework, initial unit tests covering the existing appenders, and a CI workflow to catch regressions before they merge.

What's in scope

Choose and configure a test runner that works with Bun (e.g., bun test, Vitest, or similar)
Set up a test/ directory with at least one test file per log appender (Console, Buffer, Noop)
Add test and test:coverage scripts to package.json
Verify the existing threshold bug (this.threshold && treating 0 as falsy) is caught by a test
Create a Gitea Actions workflow (.gitea/workflows/validate.yml or similar) that runs bun test on push/PR

What's out of scope

100% coverage target — we'll get there incrementally
Integration or E2E tests — unit tests only for this issue
Linting or formatting checks (those can be separate issues)

Acceptance criteria

bun run test runs all unit tests and reports pass/fail
bun run test:coverage reports test coverage
Every existing log appender has at least basic unit tests
A Gitea Actions workflow runs bun test on PRs and reports status
Tests catch the falsy this.threshold edge case for LogLevel.ALL = 0

### Problem sheer `js-logging` currently has no automated tests. As the library grows (three appenders already, more on the way), manual verification isn't sustainable. We need a test framework, initial unit tests covering the existing appenders, and a CI workflow to catch regressions before they merge. ### What's in scope - Choose and configure a test runner that works with Bun (e.g., `bun test`, Vitest, or similar) - Set up a `test/` directory with at least one test file per log appender (Console, Buffer, Noop) - Add `test` and `test:coverage` scripts to `package.json` - Verify the existing threshold bug (`this.threshold &&` treating 0 as falsy) is caught by a test - Create a Gitea Actions workflow (`.gitea/workflows/validate.yml` or similar) that runs `bun test` on push/PR ### What's out of scope - 100% coverage target — we'll get there incrementally - Integration or E2E tests — unit tests only for this issue - Linting or formatting checks (those can be separate issues) ### Acceptance criteria - `bun run test` runs all unit tests and reports pass/fail - `bun run test:coverage` reports test coverage - Every existing log appender has at least basic unit tests - A Gitea Actions workflow runs `bun test` on PRs and reports status - Tests catch the falsy `this.threshold` edge case for `LogLevel.ALL = 0` ### Related - PR #1: `feat: add console, buffer, and noop log appenders`

jdb commented

2026-05-05 18:56:57 +00:00

@mahseiah_ai I agree. I think there is only one open questions: Which test runner should we use? This is a very lightweight library. I am leaning towards using bun test to avoid bringing in any additional dependencies. I think that will meet our needs.

Regarding Gitea Actions, in addition to running on PRs, we should run on pushes to main as that is allowed on this repo.

I think we can tackle this scope in one PR, but I would like to break it up into multiple commits:

stand up the test runner scaffolding and structure with a single, minimal test to prove out the pattern
add the test and test:coverage scripts to package.json
create the Gitea Actions workflow running on PRs and pushes to main
add additional tests (including coverage for the threshold bug)

If there are any other questions, let's discuss. Otherwise, please assign this issue to yourself, create a branch, work the plan above, and push up a PR. I'll review

@mahseiah_ai I agree. I think there is only one open questions: Which test runner should we use? This is a very lightweight library. I am leaning towards using `bun test` to avoid bringing in any additional dependencies. I think that will meet our needs. Regarding Gitea Actions, in addition to running on PRs, we should run on pushes to main as that is allowed on this repo. I think we can tackle this scope in one PR, but I would like to break it up into multiple commits: - stand up the test runner scaffolding and structure with a single, minimal test to prove out the pattern - add the `test` and `test:coverage` scripts to `package.json` - create the Gitea Actions workflow running on PRs and pushes to `main` - add additional tests (including coverage for the threshold bug) If there are any other questions, let's discuss. Otherwise, please assign this issue to yourself, create a branch, work the plan above, and push up a PR. I'll review

mahseiah_ai commented

2026-05-05 18:57:26 +00:00

Sounds great! bun test is the right call for a lightweight library like this — no extra deps, and it works natively with Bun.

I'll follow the commit plan exactly:

Test scaffolding + minimal proof-of-pattern test
test and test:coverage scripts
Gitea Actions workflow (PRs + pushes to main)
Full test suite including the threshold bug coverage

Assigning to myself and getting started now.

Sounds great! `bun test` is the right call for a lightweight library like this — no extra deps, and it works natively with Bun. I'll follow the commit plan exactly: 1. Test scaffolding + minimal proof-of-pattern test 2. `test` and `test:coverage` scripts 3. Gitea Actions workflow (PRs + pushes to `main`) 4. Full test suite including the threshold bug coverage Assigning to myself and getting started now.

mahseiah_ai self-assigned this 2026-05-05 18:57:31 +00:00

mahseiah_ai referenced a pull request that will close this issue

2026-05-05 19:08:09 +00:00

Add test framework, unit tests, and CI validation workflow #3

mahseiah_ai commented

2026-05-05 19:08:54 +00:00

PR is up: #3

All four commits are in, 38 tests passing across 6 files. A few notes:

bun test works cleanly with zero additional deps — TypeScript source imported directly from ../src/ with native type stripping.
ConsoleLogAppender tests don't use spyOn(console, ...) because Bun captures console.log references at import time, so runtime overrides don't intercept. Instead tested threshold/formatter logic via formatter call counting and not.toThrow() assertions.
Fixed a bug while I was there: src/index.ts was missing the BufferLogAppender barrel export. Included in the final commit.
The threshold falsy bug (this.threshold && with LogLevel.ALL = 0) is covered in logger.test.ts, buffer-log-appender.test.ts, and console-log-appender.test.ts. Interestingly, in the appenders the && guard accidentally works correctly (0 is falsy so the if block is skipped and messages proceed), but in Logger.getEffectiveThreshold() it's a real bug — you can verify by running the tests which would fail if that logic regressed.

PR is up: #3 All four commits are in, 38 tests passing across 6 files. A few notes: - **bun test** works cleanly with zero additional deps — TypeScript source imported directly from `../src/` with native type stripping. - **ConsoleLogAppender tests** don't use `spyOn(console, ...)` because Bun captures `console.log` references at import time, so runtime overrides don't intercept. Instead tested threshold/formatter logic via formatter call counting and `not.toThrow()` assertions. - **Fixed a bug while I was there**: `src/index.ts` was missing the `BufferLogAppender` barrel export. Included in the final commit. - The **threshold falsy bug** (`this.threshold &&` with `LogLevel.ALL = 0`) is covered in `logger.test.ts`, `buffer-log-appender.test.ts`, and `console-log-appender.test.ts`. Interestingly, in the appenders the `&&` guard accidentally works correctly (0 is falsy so the `if` block is skipped and messages proceed), but in `Logger.getEffectiveThreshold()` it's a real bug — you can verify by running the tests which would fail if that logic regressed.

jdb closed this issue

2026-05-05 20:07:14 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jdb/js-logging#2