Unit Testing

I have been working on computer software since I had entered 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 product at the begining of project but make project adaptable to 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 software is being developed, customer may change mind or requirements of 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 for 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;

(Script is available here. You must have necessary privileges to execute the script.)

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.

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 expense of unit testing to developer, is actually a 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 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

Code listing

[1] http://www.ozgurmacit.com/files/Unit-testing-01.sql

3 Responses to “Unit Testing”


  1. 1 steven feuerstein Feb 20th, 2007 at 23:48

    Ozgur,

    This is a fantastic posting! I wish and hope that more and more Oracle technologists will bring attention to bear on the issue of testing in the world of PL/SQL.

    I certainly have become obsessed by it. Thanks for telling people about Qute. I thought you’d want to get an update.

    Qute is now Quest Code Tester for Oracle, and we just released it as a commercial product (version 1.5.1) last week. For more info:

    http://www.quest.com/code-tester-for-oracle

    It has come a VERY VERY long way since the days of Qute (I really liked that name!) and I encourage you to at least download and install the trial version and check it out.

    Note: there is a freeware version of Quest Code Tester available at ToadWorld.com; it is still stuck in the 1.2.5.5 release, but we will be updating it soon to 1.5.1.

    Now, in terms of your concerns, you wrote:

    Ozgur: It needs a schema to keep its own tables, etc. This is an obligation, though.

    Steven replies: Well, yes, this product has an Oracle backend with some 38 tables and 146 packages. So it needs *some* schema or other, but you can usually install it into the standard HR or SCOTT schema, as long as you have CREATE TYPE privilege (I think that is the only “unusual” privilege) defined on it. Also, in the commercial version (including trial), we will check the privs on your schema to make sure the install will work. For most shops installing Code Tester for “real” use, they would install it into its own separate schema, with public synonyms, so that it can be used from any schema on the instance.

    Ozgur: It needs several privilages to be given to that user to run test cases againist objects on other schemas.

    Steven replies: Code Tester relies on the Oracle privileges architecture to determine what you can run (and test). Suppose I install Code Tester in schema QCTO, with public synonyms. My application code is in schema CODE. I then connect to CODE, and can build tests for my application right there. No special privs are needed in the QCTO schema to do this. If you do not install with public synonyms, then you will need to connect to the QCTO schema to run Code Tester and you will only be able to see/test programs on which the QCTO schema has execute authority. There is nothing unusual to Code Tester about this; it is the way Oracle works.

    I hope this clarifies your concerns. Thank you again for your posting on unit testing. I look forward both to the discussion it generates and to any and all feedback PL/SQL developers have on Quest Code Tester!

    Warm regards,
    Steven Feuerstein
    PL/SQL Evangelist
    Quest Software

  2. 2 cheap viagra Jun 20th, 2008 at 22:13

    cheap viagra online
    <a href="http://www.epinions.com/user-dr-lerman/show_~View_Profile" rel="nofollow">cheap viagra</a>
    http://www.epinions.com/user-dr-lerman/show_~View_Profile
    [url=http://www.epinions.com/user-dr-lerman/show_~View_Profile]cheap viagra[/url]
    <a href="http://www.hackint0sh.org/forum/member.php?u=67677" rel="nofollow">buy viagra online</a>
    http://www.hackint0sh.org/forum/member.php?u=67677
    [url=http://www.hackint0sh.org/forum/member.php?u=67677]buy viagra online[/url]

  1. 1 Log Buffer #56: a Carnival of the Vanities for DBAs « H.Tonguç YILMAZ Oracle Blog Pingback on Oct 17th, 2007 at 10:45

Leave a Reply