Rajarshee Chatterjee
53 lines
2.5 KiB
Markdown
53 lines
2.5 KiB
Markdown
# Testing your plugin
|
|
|
|
`tsc`, ESLint, and Prettier all check that your plugin _compiles_. None of them can tell you
|
|
whether it actually returns novels, chapters, or search results from the real site — plugins fail
|
|
in ways the compiler can't see, because the wiki/site content they scrape has no schema: an empty
|
|
chapter list, a chapter body that's actually a "back to top" nav page, search results leaking
|
|
pages in the wrong language, and so on.
|
|
|
|
## `npm run check:plugin`
|
|
|
|
Bundles your plugin with esbuild the same way the production build does, then runs it against the
|
|
live site — calling `popularNovels`, `searchNovels`, `parseNovel`, and `parseChapter` in sequence,
|
|
using your plugin's own default filter values (the same values the app would send).
|
|
|
|
```sh
|
|
npm run check:plugin -- plugins/english/yourPlugin.ts
|
|
```
|
|
|
|
You can check multiple plugins in one run:
|
|
|
|
```sh
|
|
npm run check:plugin -- plugins/english/yourPlugin.ts plugins/english/anotherPlugin.ts
|
|
```
|
|
|
|
Each step reports one of three outcomes:
|
|
|
|
- **PASS** — got a plausible result (non-empty novel list, a chapter body over ~200 characters,
|
|
etc).
|
|
- **FAIL** — the plugin ran but returned something wrong (empty results, a novel with no chapters,
|
|
a suspiciously short chapter body, or a thrown error that isn't network-related). This is what
|
|
you're looking for before opening a PR.
|
|
- **INCONCLUSIVE** — the site itself was unreachable, timed out, or returned a Cloudflare-style
|
|
block during this run. Not a plugin bug; re-run later or check the site manually.
|
|
|
|
## CI
|
|
|
|
Any PR that touches a file under `plugins/**/*.ts` (excluding multisrc-generated files) runs this
|
|
same check automatically against just the changed plugins, and posts the results as a job summary
|
|
on the workflow run (visible from the PR's checks list, under the Actions tab) — not as a PR
|
|
comment. The check only fails the PR on a genuine `FAIL` — `INCONCLUSIVE` results (a site being
|
|
briefly down) never block a merge.
|
|
|
|
You can also trigger it manually against any plugin path from the Actions tab
|
|
(`Plugin Live Check` → `Run workflow`), which is useful for re-checking an existing plugin after
|
|
its target site changes layout.
|
|
|
|
## See also
|
|
|
|
`check:plugin` catches wrong/missing data automatically, but it's not a substitute for actually
|
|
looking at the output. See the [website tutorial](./website-tutorial.md) for testing your plugin
|
|
interactively in the browser — useful for spot-checking filters, pagination, and chapter
|
|
formatting by eye before opening a PR.
|