Skip to content

Repository files navigation

jdot-testing

Offline test-fixture generation and testing tools for JDot Utilities.

JDot Utilities is a local file-conversion and PDF toolkit; exercising it well means feeding it a wide, varied pile of input files with known properties. Hunting down real documents that hit every edge — big page counts, scanned vs selectable text, colour vs grayscale, embedded photos, awkward filenames — is tedious and non-reproducible. This repo manufactures them on demand instead.

It is organised into sections, one per testing capability. Each section is self-contained and adds its own command.

Section What it does Status
File Creation (sections/file-creation/) Generate corpora of test files with controlled properties + a ground-truth manifest. Formats: PDF and images (png/jpg/webp), via --type. Active
Validation (sections/validation/) Feed a corpus through JDot Utilities' real tools and check the app against the manifest (round-trip). Active

Requirements

  • Node 22+ (the test script's node --test glob needs 21+).
  • No external services, no network access — pure JS plus prebuilt-binary libraries (pdf-lib, @napi-rs/canvas), matching JDot Utilities' offline promise.

Install

git clone https://github.com/AxialForge/jdot-testing
cd jdot-testing
npm install

GUI

A desktop app (Electron) for File Creation — pick PDF or image, set options, choose a folder, Generate:

npm start            # launch the GUI
npm run build:gui    # portable .exe → dist-gui/

See gui/README.md. The CLI below does the same thing headlessly.

Run

Section 1 — File Creation. Generate a PDF corpus (defaults: 150 files, 3–110 pages):

npm run create:pdf

Options (full list via node sections/file-creation/pdf --help):

npm run create:pdf -- --count 20 --pages 1-6 --seed demo
npm run create:pdf -- --text scanned --color gray --dpi 200

Output lands in test-corpus/pdf/ (git-ignored): the *.pdf files plus manifest.json / manifest.csv recording every file's real properties. See sections/file-creation/README.md for details.

Images work the same way (png/jpg/webp; photo or OCR-readable text):

npm run create:image -- --count 20 --content text --format png
npm run create -- --type image     # or via the dispatcher

Validate (Section 2)

Feed a corpus through JDot Utilities' real tools and check the app against the manifest. Point --app at a checkout of the app (with its deps installed):

npm run validate -- --corpus test-corpus/pdf --app ../jdot-utilities

It runs PDF → Text and (for scans) OCR → Text, asserts each result against the manifest's ground truth, writes validation-report.json, and exits non-zero on any mismatch. See sections/validation/README.md.

Download

Tagged releases attach standalone command-line binaries (no clone or Node needed) on the Releases page:

Platform Asset
Windows x64 jdot-create-pdf-win-x64.exe
Linux x64 jdot-create-pdf-linux-x64
macOS arm64 jdot-create-pdf-macos-arm64

Run from a terminal — it writes to test-corpus/pdf/ under the current directory:

jdot-create-pdf-win-x64.exe --count 20 --pages 3-40 --seed demo
chmod +x jdot-create-pdf-linux-x64 && ./jdot-create-pdf-linux-x64 --help

The Linux/macOS binaries need chmod +x; the macOS one is unsigned, so Gatekeeper needs a one-time allow (xattr -d com.apple.quarantine <file> or right-click → Open). Full flags: <binary> --help.

Keeping a binary up to date

The binaries self-update (opt-in — nothing phones home unless you ask):

jdot-create-pdf-win-x64.exe --version        # this build's version
jdot-create-pdf-win-x64.exe --check-update   # is there a newer release?
jdot-create-pdf-win-x64.exe --update         # download + verify + replace in place

--update pulls the matching platform binary from the latest GitHub release, verifies it (size, executable magic bytes, and the published SHA-256), and swaps it in; your existing binary is left untouched if anything fails. From a source checkout, just git pull instead.

Test

npm test

Build the .exe (Windows)

npm run build:exe   # → dist/jdot-create-pdf.exe

CI builds this on a version tag; local builds are just for testing packaging.

Development

Architecture, the section/extension model, and any accumulated gotchas are in CLAUDE.md. Read it before changing anything structural.

License

MIT — see LICENSE.

About

Offline test-fixture generation and testing tools for JDot Utilities (Section 1: File Creation).

Topics

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages