Unit Test Manager

Author, organise and run repeatable PL/SQL tests. Suites and their results are stored locally by DBCraft — nothing is installed in your database.

#21.1Layout

Left column — your test suites for this connection. Each shows a pass count (green), a fail count (red), and the last-run time. A dot appears next to a suite with unsaved edits.
Right pane — the suite editor, with a toolbar and three tabs: Definition, Notes, Run.

#21.2Creating a suite

+ in the left header, or New Test Suite on the toolbar. Give the suite a Suite Name and an optional Description, then Create Suite.

Button	Action
📄+	New Test Suite.
📂	Import Test Suite — reads a `.dbctest.json` file.
💾	Save — enabled only when there are unsaved changes.
💾↓	Export Test Suite — writes the suite to a `.dbctest.json` file for version control or for sharing with a colleague.
▶	Run — runs the suite.

While running, a progress bar and percentage appear next to the Run button.

#21.4Defining test scripts (Definition tab)

The upper list shows the scripts in execution order, numbered, each with a status icon and badges for new session, disabled, and any performance limit. The buttons down the right side:

Button	Action
+	Add a new test script.
×	Remove the selected script.
↑ / ↓	Move the selected script up or down — this is the execution order.
📂	Load script from file — replaces the selected script’s SQL from a `.sql`, `.pls`, `.pks`, `.pkb` or `.txt` file.

The Definition fieldset below edits the selected script:

Field	Meaning
Name	The test’s name, shown in results.
Description	Free text.
Object Name	The program under test, e.g. `HIRE_EMP`. Used by Launch in Debugger when the test fails.
Test script	The PL/SQL to execute. Defaults to a template using the `:out_result` bind.
Expected output	What `:out_result` must equal for the test to pass. Use `*` to accept any output.
New session	Run this script on its own connection instead of the suite’s shared session. Use it to test something that depends on a fresh session state.
Enabled	Unticked scripts are skipped by a run (reported as skipped, not failed).
Performance	A time limit in seconds. If the script takes longer, it fails. Blank means no limit.

How pass/fail is decided:

If the script assigns the :out_result bind variable, its value is compared with Expected output. * accepts anything.
If the script binds nothing, it passes if it runs without raising an error.
Any Oracle error fails the test, and the error message is shown in the results.
Exceeding the Performance limit fails the test.

Example:

sql

BEGIN
  :out_result := hire_emp(p_name => 'TEST', p_dept => 20);
END;

with Expected output SUCCESS.

#21.5Notes tab

Edit the Suite Name, Description and a free-form Notes field — the right place for setup requirements, known issues and ownership.

#21.6Running a suite

Press ▶. What happens:

Any unsaved edits are saved first — the run always executes what is on disk.
One shared database session is opened for the suite.
Each script runs in order. Scripts marked New session get their own connection.
Results stream into the Run tab as each script finishes.
The shared session is closed at the end, and the suite counters are refreshed.

#21.7Reading results (Run tab)

A summary bar shows Passed, Failed, Skipped and a Pass Rate percentage (green at 100 %, amber at 80 % or above, red below).

Each script gets a card with its status icon, name, description, duration in milliseconds, and a status badge. A failure expands to show:

The error message, in a red monospaced block.
The Actual Output, when the script produced one.
A Launch in Debugger button (when an Object Name is set) that opens the debugger pre-loaded with that procedure and execution block.