You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When launching SumatraPDF.exe for ad-hoc testing, always pass the `-for-testing` cmd-line flag. It starts a new instance (won't interfere with an already running SumatraPDF), doesn't restore the previous session (only loads files given on the cmd-line) and doesn't save settings (won't overwrite the settings of the user).
16
16
17
-
After making a change to .cpp, .c or .h file (and before running build.ts), run clang-format on those files to reformat them in place
17
+
After making a change to a .cpp, .c or .h file under `src/`(and before running build.ts), run clang-format on those files to reformat them in place. Do **not** clang-format third-party / vendored code (`mupdf/`, `ext/`, etc.) — keep edits there minimal and match the existing local style.
18
18
19
19
Never commit changes automatically. Always wait for explicit command to commit changes.
20
20
21
+
When committing a fix for a GitHub issue, include `(fixes #<issue-no>)` at the end of the commit message.
22
+
21
23
## Adding a new advanced setting
22
24
23
25
To add a new advanced setting:
@@ -40,6 +42,42 @@ To add a new cmd-line flag:
40
42
- implement handling in Flags.cpp
41
43
- document in docs/md/Version-history.md in **next** section
42
44
45
+
## Bug reproduction / test files
46
+
47
+
We keep test and reproduction files for bugs in `C:\Users\kjk\OneDrive\!sumatra\bugs\`, named after the GitHub issue number:
48
+
- a single file is `bug-<bug-no><rest>` (e.g. `bug-534.pdf`)
49
+
- if a repro needs more than one file, use a directory `bug-<bug-no><rest>\`
50
+
51
+
When fixing a bug, look there first for an existing repro file for that issue and use it. When you create a test/repro file while working on a bug, save it there (using the naming above) after fixing the bug.
52
+
53
+
## Writing tests
54
+
55
+
Tests live in tests/ and are run with bun (e.g. `bun tests/issue-5633.ts`). Naming convention, keyed by the GitHub issue number being tested:
56
+
- the test script is `tests/issue-<number>.ts`
57
+
- if it needs a small number (one or two) of extra files, name them `tests/issue-<number>.<rest>`
58
+
- if it needs more files, or a file must live in a directory, put them in `tests/issue-<number>-data/`
59
+
60
+
Structure of each test (so they compose in tests/all.ts):
61
+
- each `tests/issue-<number>.ts` exports `export async function testit(): Promise<void>` that runs the test logic and THROWS on failure (returns normally on success). It must NOT call `process.exit` or build the app itself.
62
+
- end the file with a standalone runner so it can still be run directly:
63
+
```ts
64
+
if (import.meta.main) {
65
+
awaitrunStandalone(testit);
66
+
}
67
+
```
68
+
`runStandalone` (from `tests/util.ts`) builds the app (unless `--no-build`), runs `testit()`, and exits 0 on pass / 1 on failure.
69
+
- shared helpers (`EXE` path, `buildApp`, `runStandalone`) live in `tests/util.ts` — use them instead of re-implementing per file.
70
+
- register every new test in `tests/all.ts` (import its `testit` and add it to the `tests` array). `bun tests/all.ts` builds once and runs them all in order, stopping at the first failure.
71
+
72
+
Guidelines for test scripts:
73
+
- build the app the same way cmd/build.ts does (via `buildApp`/`runStandalone` in tests/util.ts) and test the resulting out/dbg64/SumatraPDF-dll.exe
74
+
- if a needed external tool (e.g. MiKTeX) isn't installed, don't fail the test: print a clear message (with instructions to install it) and skip that part, returning normally so `tests/all.ts` continues
75
+
- a good test fails when the fix is reverted (verify this) — not just passes with the fix present
76
+
- bun has FFI; if you need to call Windows APIs, put reusable wrappers in tests/winapi.ts
77
+
- prefer driving the app via cmd-line flags that write a machine-readable result (see `-test-synctex`) over GUI automation
78
+
- never write runtime scratch / result files directly into `tests/` — that leaves the repo dirty. Write them under `tests/tmp/` (gitignored), using `tmpPath("name")` from `tests/util.ts` (it creates the dir on demand); the OS temp dir (`os.tmpdir()`) is also fine if you clean up after
79
+
- if a binary test fixture (e.g. a .pdf) is generated from source (LaTeX, a script, etc.), commit the source alongside it (e.g. `tests/issue-<number>.tex` next to `tests/issue-<number>.pdf`) with a comment on how to regenerate it, so the fixture can be modified later
80
+
43
81
## Windows Shell Safety
44
82
45
83
The Bash tool runs under Git Bash (MSYS2), **not** cmd.exe. This causes critical issues with Windows-style commands:
0 commit comments