wtPLSQL Project

wtPLSQL is a white-box testing framework for Oracle database objects.

Website Home Page

utPLSQL V3 Comparison

Under Construction


The Basics

“ut3” is a comprehensive project. Its capabilities are a large and diverse. It is supported by many people around the world. If your development environment includes a wide variety of platforms and technologies, this is the best project for you.

“wt” is an Oracle database focused project. It is built entirely with PL/SQL and Application Express. All testing and reporting is done in the database.


The “ut3” project “follows industry standards and best patterns of modern Unit Testing frameworks like JUnit and RSpec”.

The “wt” project avoids “unit testing” by adopting practices for “white box testing”.


The “ut3” project incorporates a wide variety of technologies and platforms. It also has a large and diverse set of capabilities that will reduce the need for customization.

The “wt” project is centered on one platform with a very simple implementation. It is easier to customize smaller, simpler systems.

Testing Methodologies

There is a longer discussion about unit testing methodologies in the About wtPSQL Page.

Fundamentally, the Oracle database is a relational database. The relational database is based on transaction processing. Data is stored and shared in a precise manner between processes.

JUnit testing is OO (Object Oriented programming) based. Encapsulation is a core part of OO. Data sharing is done through APIs (Application Programmatic Interfaces), i.e. no fundamental data persistence.

The principle of “store and share” is the opposite of data encapsulation. As a result, OO testing approaches are inappropriate for relational databases.

Here are several differences in testing methodologies between relational databases and Object Oriented.

Testing Persistence of Data

Isolation of Tests

Test Transience

Non-Sequenced Testing

Test Driven Development (TDD/RSpec)

In the fast-paced development cycle, defining how the software accomplishes the needs of the business is the typical focus. This is also called “happy path” functionality. Conversely, error handling and error recovery (sad path) requirements typically don’t accomplish business needs. That is to say, sad path testing focuses on things going badly, not on things going well. Unfortunately, efforts to develop and define sad path requirements are typically avoided.

White box testing is centered on 100% code coverage. “Happy path” and “sad path” testing are typically required to achieve 100% code coverage.

Here is more discussion on Test Driven Development

Website Home Page