Skip to main content
Test a V2 node the same way users experience it: add it to a workflow, connect realistic inputs, run it, save the workflow, and load it again. MAGIC PATCH creates a migration starting point. Its output still needs the pack’s ordinary behavior and compatibility tests before release.

​
Test node behavior

For every node the extension changes, verify:
  • the node appears with the expected name, category, and badges;
  • each slot accepts and rejects the correct connection types;
  • widget defaults, minimums, maximums, and optional widgets behave correctly;
  • custom widgets, panels, previews, and menus render and update as expected;
  • lifecycle hooks run on creation, configuration, and removal without leaving stale subscriptions.
Use unit tests for pure logic. Mock comfy handles and services when a full ComfyUI host is unnecessary. Add browser tests for at least one realistic workflow that exercises the extension end to end.

​
Test workflows and serialization

Save and reload representative workflows. Confirm that:
  • node IDs and widget values survive a round trip;
  • prompt serialization contains the expected values;
  • links reconnect to the correct slots;
  • renamed or deprecated nodes migrate as intended;
  • embedded workflow data in outputs remains usable when the pack supports it.
Saved workflows, queued prompts, and workflows embedded in outputs are separate serialization destinations. Test each destination your widgets customize.

​
Test JavaScript extensions

Exercise definition hooks, widget events, graph edits, menus, commands, notifications, storage, and backend requests used by the pack. The frontend repository’s examples/node-api example packs provide executable patterns and browser-test coverage for these behaviors. Use them as a starting point for pack-specific tests rather than relying only on static snippets. Check that compound graph edits create the intended undo step and that removed nodes or widgets do not leave stale subscriptions behind. For routes that require host authentication, use comfy.backend.fetch() in the test path so a bare fetch() does not hide an authentication problem.

​
Test the pack layout

For a converted pack, the installation contains two complete alternative pack roots:
  • the existing V1 distribution at the top level;
  • the V2 replacement distribution under v2/.
Test that the root V1 entrypoint still loads and that the V2 loader finds v2/__init__.py and serves the frontend module from v2/web/. V2 frontend files, dependencies, metadata, and assets must resolve from the V2 tree without falling back to a similarly named V1 file. A packaging test should reject an incomplete v2/ tree, flattened V2 files, missing required assets, or an accidental v2/v2/ directory.

​
Check API compatibility

  • Type-check JavaScript or TypeScript against comfy-api.d.ts.
  • Import only published modules.
  • Keep a released pack on a supported major with comfy.forMajor().
  • Regenerate reference docs when the declaration snapshot changes.

​
Test supported environments

Run the main V2 workflow in every ComfyUI version and renderer the pack claims to support. The schemas, refs, outputs, and frontend behavior should remain consistent. If part of the pack deliberately reaches into private Python backend or web-page internals, label that feature clearly and verify that the rest of the pack still behaves when the feature is unavailable.

​
Documentation checks

Before release, verify:
  • setup instructions work from a clean pack install;
  • every copied example parses or type-checks;
  • navigation and internal links resolve;
  • search finds the pack’s important classes, methods, and services;
  • code blocks and tables are readable in light and dark mode.