I have been working on computer software since I had entered the university in September 2002. It has been more than four years and no single unit testing experimantation all I have. Of course I test my code, but not having any theoretical or methodological background. I only gave a few suspicious input to my program and checked the output, that is all. Thus, big black boxes, all my programs were.

Test Driven Development

On this site Test Driven Development is summarized in this way:

Test Driven Development (TDD) is a software engineering methodology that states that all code should have a set of clear, repeatable unit tests written for it. Furthermore, it states that these tests should be written before the corresponding code is written, thus driving the development of the code base.

That sounds good: While I prepare my test cases before development phase I am able to think about them free of implementation. Moreover, once I have thought of test cases (that is, possible failure cases) I may write my code much more efficient and bug-free. There is no need to discuss how big effect bugs have in software production. Just let me say, software bugs may cause a big money loss, or even human life in some cases. We don’t love them, we will never love :)

Extreme Programming

Extreme Programming is defined as “Extreme Programming differs from traditional methodologies primarily in placing a higher value on adaptability than on predictability” in Wikipedia. The methodology of Extreme Programming is not to predict all requirements of the product at the begining of the project but make the project adaptable to the changing requirements. That’s the way a software project has a chance to be successful in our day. Projects are developed in months or even years occasionally. While the software is being developed, customer may change mind or the requirements of the market may change. This requires a fast-alterible programming methodology like Extreme Programming.

Qute

Unit testing is the corner stone of Extreme Programming ([1]). That’s why Steven Feuerstein works on a unit testing tool for PL/SQL :)
Lucas Jellema gives a brief introduction about Qute (Feuerstein’s unit testing tool) before giving helpful information about how to install the program and a tutorial to explain how the program runs in his article. In the same article he quotes from Steven Feuerstein “Qute is the Quick Unit Test Engine. It is a tool for defining unit tests, generating test code, and running those tests, all within a graphical interface“.
The thing I found exciting in Qute is it has an easy to use GUI, so you do not need to write even one line of code to create test cases or run them againist your code. With four years in school and six months of work experience with them, I learned that developer is somebody who is lazy as a cat :) This tool is something for them (us?).

You can download Quest Code Tester for Oracle here (you must be a registered user to download the file – and smile, registration is free fow now).
Unfortunately, I have faced a problem while installing this software on my computer. Since a new user does not have some privilages required, installation had failed. I created a user of my own and re-installed the software:

DROP USER qute;
CREATE USER qute IDENTIFIED BY qute;
GRANT CONNECT, RESOURCE, DBA TO qute;
GRANT EXECUTE ON utl_file TO qute;

And I tested the test tool with a simple package. All I have done is writing this code and compiling it on any schema, say HR, then granting execute on this package to the user qute, or whatever schema Qute is installed. Then I open Qute and generate test cases for this package and simply run the test. That’s all. I did not write a simple line of code for testing. Here is my package:

CREATE OR REPLACE PACKAGE BODY pkg_calc IS

g_res NUMBER;

FUNCTION square(pin_x NUMBER) RETURN NUMBER IS
y NUMBER;
BEGIN
IF (pin_x IS NULL)
THEN
y := 0;
ELSE
y := pin_x * pin_x;
END IF;
g_res := y;
RETURN(y);
END square;

FUNCTION square_res RETURN NUMBER IS
y NUMBER;
BEGIN
y := g_res * g_res;
g_res := y;
RETURN(y);
END square_res;

END pkg_calc;

What I don’t like about Qute is:

• It needs a schema to keep its own tables, etc. This is an obligation, though.
• It needs several privilages to be given to that user to run test cases againist objects on other schemas.

What I like about Qute is, I can now say “here is my documentation, if you update my code, your new code should success those cases”. That’s enough for me.

Unit testing activities

Following list is completely copied from [3].

1. Perform test planning phase
   1. Plan the general approach, resources, and schedule
   2. Determine features to be tested
   3. Refine the general plan
2. Acquire test set phase
   1. Design the set of tests
   2. Implement the refined plan and design
3. Measure test unit phase
   1. Execute the test procedures
   2. Check for termination
   3. Evaluate the test effort and unit

Benefits of unit testing

In Wikipedia it is claimed that “Unit testing is typically done by the developers and not by end-users“. This fact, however it seems to be the expense of unit testing to the developer, is actually the benefit of unit testing.
First of all, since unit testing methodology assumes that test cases are prepared before the implementation phase, test cases becomes roadmaps of actual implementation. Programmers just have to be aware of test cases to reduce the cost of maintenance.
Secondly, Unit Testing provides a sort of “living document” [2]. Same article on Wikipedia continues like this:

Unit test cases embody characteristics that are critical to the success of the unit. These characteristics can indicate appropriate/inappropriate use of a unit as well as negative behaviors that are to be trapped by the unit.

Unit testing documentation methodology serves a permanent information about the software. This information is what is expected from the software and this does not change unless the expectations are modified. That results in an easily maintained software. Whereas, ordinary documentation is highly related with how the program is implemented and requires to be updated frequently [2].

References

[1] http://en.wikipedia.org/wiki/Extreme_Programming : Extreme Programming
[2] http://en.wikipedia.org/wiki/Unit_test : Unit testing
[3] http://iteso.mx/~pgutierrez/calidad/Estandares/IEEE%201008.pdf : IEEE Standard for Software Unit Testing
[4] http://technology.amis.nl/blog/?p=1041 : Qute – new Unit Testing Engine for PL/SQL (successor for utPLSQL) by Lucas Jellema
[5] http://www.apollo-pro.com/help/pl_unit.htm