In August, I wrote on utPLSQL site, that utPLSQL needs a clear vision for its future, and that the project cannot keep going on after-hours goodwill alone. This is the first concrete step in that direction. In August 2026 I incorporated utPLSQL Development Labs Ltd in Cyprus, where I now live, and utPLSQL is moving under its custody.
Before I explain what that means, let me explain how a unit testing framework for PL/SQL ended up needing a company at all.
utPLSQL comes with several output reporters for different use cases: human-readable text, JUnit XML, TeamCity, TFS for CI pipelines, SonarQube-compatible coverage reports and more.
Throwing exceptions is a common practice of handling situations when the program meets unsupported combination of data or conditions. Oracle PL/SQL language provides several mechanisms for raising and capturing exceptions.
utPLSQL provides the --%throws annotation that allows for verification of expected exceptions.
Exception testing in utPLSQL is done through this annotation, not through ut.expect(...).
utPLSQL can compare results of two queries in single line call to ut.expect(). Within your test, define the SQL queries as SYS_REFCURSOR variables.
utPLSQL provides expectations syntax through the ut.expect() methods. This post covers the most commonly used expectation matchers and how failure output works.
You configure utPLSQL test suite in special comments — called annotations — right inside the PL/SQL package specification.
Annotations are comment lines starting with --%. They tell the framework what is a suite, what is a test, what procedures need to be called for setup or cleanup logic. The framework reads them at runtime so no extra configuration is needed.
Testing PL/SQL code does not need to mean writing throwaway scripts or using a complicated graphical user interface.
utPLSQL gives you a proper test framework — right inside database.
A utPLSQL test is just a package annotated as --%suite with procedures annotated as --%test. The framework finds them automatically.