-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathutPLSQL-V3-Comparison.htm
More file actions
47 lines (47 loc) · 4.26 KB
/
Copy pathutPLSQL-V3-Comparison.htm
File metadata and controls
47 lines (47 loc) · 4.26 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
<p><a href="README.htm">Website Home Page</a></p>
<h1 id="utplsql-v3-comparison">utPLSQL V3 Comparison</h1>
<hr />
<p>utPLSQL V3 is an excellent choice for unit testing. It is well supported and includes extensive functionality. wtPLSQL has a different focus than utPLSQL V3.</p>
<h2 id="utplsql-v3">utPLSQL V3</h2>
<p>utPLSQL V3 is a comprehensive project. Its capabilities are large and diverse. It 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. It is supported by many people around the world.</p>
<p>If your development environment includes a wide variety of platforms and technologies, you should consider using utPLSQL V3.</p>
<h2 id="wtplsql">wtPLSQL</h2>
<p>wtPLSQL is Oracle database focused. It is built entirely with PL/SQL and Application Express. All testing and reporting is done in the database. Because it is centered on the Oracle database, it is a very simple implementation. With hooks and add-ons, it easy to customize.</p>
<p>If your development environment is heavily invested in PL/SQL and the Oracle database, wtPLSQL is built for you.</p>
<h2 id="testing-methodologies">Testing Methodologies</h2>
<p>There is a longer discussion about unit testing methodologies in the <a href="https://github.com/DDieterich/wtPLSQL/wiki/About-wtPLSQL#unit-testing">About wtPSQL Page</a>.</p>
<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>
<ul>
<li>Object Oriented - Use fakes or mocks to avoid any data persistence.</li>
<li>Relational Database - Testing of data persistence is fundamental.</li>
</ul>
<h3 id="isolation-of-tests">Isolation of Tests</h3>
<ul>
<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>
</ul>
<h3 id="test-transience">Test Transience</h3>
<ul>
<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>
</ul>
<h3 id="non-sequenced-testing">Non-Sequenced Testing</h3>
<ul>
<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>
</ul>
<h3 id="test-driven-development-tddrspec">Test Driven Development (TDD/RSpec)</h3>
<p>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.</p>
<p>White box testing is centered on 100% code coverage. "Happy path" and "sad path" testing are typically required to achieve 100% code coverage.</p>
<p>Here is more discussion on <a href="About-wtPLSQL.htm#test-driven-development">Test Driven Development</a></p>
<h3 id="links">Links</h3>
<ul>
<li><a href="https://utplsql.org">utPLSQL V3 Website</a></li>
<li><a href="http://utplsql.org/documentation/">utPLSQL V3 Documentation</a></li>
</ul>
<hr />
<p><a href="README.htm">Website Home Page</a></p>