<p><a href="README.htm">Website Home Page</a></p>

<h1 id="oo-style-unit-testing">OO Style Unit Testing</h1>

<hr />

<p>The wtPLSQL project focuses on white box testing instead of OO style unit testing. This is done to avoid some aspects of OO style unit testing that are not database friendly:</p>

<li>Test Isolation</li>

<li>Test Transience</li>

<li>Test Fixtures</li>

<li>Test Suites</li>

<h3 id="test-isolation">Test Isolation</h3>

<p>A unit test should <a href="https://en.wikipedia.org/wiki/Unit_testing#Description">usually not go outside of its own class boundary</a></p>

<p>In OO (object oriented) programming, object data is transient. This is due to the nature of object instantiation. Persistence of object data beyond the instance of an object is banished to non-OO components. Since the unit test movement gained its largest following in OO, the idea of testing persisted object data is, unfortunately, a distraction. This has evolved into the idea that testing a database interface should always involve the use of a <a href="https://en.wikipedia.org/wiki/Test-driven_development#Fakes.2C_mocks_and_integration_tests">fake or mock</a> to <strong>isolate</strong> the unit under test from the influence of these non-OO components.</p>

<p>Transactional data (ACID compliance) introduces a complexity to the persistence of object data. Attempting to fake this complexity is very difficult. Particularly difficult is the determination of how much functionality to include in the fake, especially when the storage of the data is the main purpose for the system. Focusing on white box testing, instead of unit testing, allows Test Runners that use the wtPLSQL server to test integrated functionality from other system components.</p>

<h3 id="test-transience">Test Transience</h3>

<p>A unit test should set up a known good state before the tests and <a href="https://en.wikipedia.org/wiki/XUnit#Test_fixtures">return to the original state after the tests</a></p>

<p>There are many arguments to be made regarding the idea of a known good state in a database. The only sure way to achieve a known good state is to leave the the database unchanged after a unit test. Ideally, changes made by a test process would be <strong>transient</strong>, that is the process would setup (insert) and tear down (delete) data in the database. However, many Oracle database implementations include additional functionality that can make this difficult.</p>

<li>Complex data setup</li>

<li>Additional processing that is unknown or poorly defined</li>

<li>Built-in auditing</li>

<p>With the wtPLSQL server, Test Runners are allow to perform integration testing of multiple database objects (no mocks or fakes). That is, the Test Runners are not bounded by the <strong>transience</strong> aspect of unit testing. Artifacts from multiple test runs can remain in the database after the testing is complete. Additionally, artifacts that remain after testing can help identify other problems in the database.</p>

<h3 id="test-fixtures">Test Fixtures</h3>

<p><a href="https://en.wikipedia.org/wiki/XUnit#Test_fixtures">A test fixture ... is the set of preconditions or state needed to run a test</a></p>

<p>An Oracle database loaded with test data is a fixture. In OO terms, it is a persistent store that is pre-loaded with data. If the test data is pre-loaded, there is no need to setup test fixtures. wtPLSQL does not require test fixtures. They are optional.</p>

<h3 id="test-suites">Test Suites</h3>

<p><a href="https://en.wikipedia.org/wiki/XUnit#Test_suites">A test suite is a set of tests that all share the same fixture.</a></p>

<p>wtPLSQL does not require test suites. If needed, test suites can be defined and implemented in Test Runner packages. The "test_all" functionality of wtPLSQL creates a form of test suite at the database schema level.</p>

<h2 id="testing-methodologies">Testing Methodologies</h2>

<p>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.</p>

<p>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.</p>

<p>The principle of "store and share" is the opposite of data encapsulation. As a result, OO testing approaches are inappropriate for relational databases.</p>

<p>Here are several differences in testing methodologies between relational databases and Object Oriented.</p>

<h3 id="testing-persistence-of-data">Testing Persistence of Data</h3>

<li>Object Oriented - Use fakes or mocks to avoid any data persistence.</li>

<li>Relational Database - Testing of data persistence is fundamental.</li>

<h3 id="isolation-of-tests">Isolation of Tests</h3>

<li>Object Oriented - Use fakes or mocks to avoid any "integration" testing.</li>

<li>Relational Database - Isolating PL/SQL code from database CRUD (Create, Retrieve, Update, Delete) defeats the purpose of most PL/SQL testing.</li>

<h3 id="test-transience-1">Test Transience</h3>

<li>Object Oriented - Return object to original state.</li>

<li>Relational Database - Integrity constraints on complex persisted data and/or complex data operations make simple test transience more difficult. An alternative is to add new data during each test and/or reset the database to a known test data set before testing.</li>

<h3 id="non-sequenced-testing">Non-Sequenced Testing</h3>

<li>Object Oriented - All unit tests should be able to run in any order.</li>

<li>Relational Database - Testing with integrity constraints on complex persisted data and/or complex data operations can be simpler with test sequencing.</li>

<hr />

<p><a href="README.htm">Website Home Page</a></p>