Just to be perfectly clear, I should note at the outset that the word "testing" in title of this article is not referring to certification exams or practice tests. In my opinion, both of these are not part of the learning process, but rather a means of determining the effectiveness of the learning process.

This article is about using test cases to answer questions you may come up with when learning a new skill. In my experience, the vast majority individuals who are preparing for certification exams do so using one or more of the following five methods:

• Reading books or study guides written for the exam
• Reading product documentation
• Reading articles posted online
• Making use of computer-based-training or recorded video training
• Attending a training class

None of these are bad things, and I highly recommend incorporating several of them into your learning process. None of the above methods, however, focuses on working with the software or hardware product itself. If the only methods used to prepare for a certification come from the above list, it is entirely possible to earn a credential for a product that you have never physically interacted with.

Experienced IT professionals refer to people like this as "paper professionals" — and that is not a term of endearment. If you hold a certificate that indicates you are knowledgeable about a software product that you have never actually used, no one (including you) should give the credential much weight.

When you are employed to perform a given task using software product X, there is no uncertainty about what you need to do. Depending on your knowledge level, determining how you will perform the task may be a great deal harder. By contrast, if you are simply playing with the software on your own in order to learn how to use it, then the first question that must be answered is what exactly to do. Randomly clicking icons or typing in commands is not likely to get you very far.

Test cases are one way to come up with a "what" to do that can lead to learning "how" to do it. What is even more important is that, unlike some aspects of the learning process, designing and building test cases is not a crutch that you discard once you become more experienced. Many of the most respected Oracle experts in the field build test cases all the time.

I answer questions on a number of forums about the Oracle database. Many of the questions posed on the forums I can answer off the top of my head. Others I can locate an explanation for in Oracle's product documentation. When those methods fail and a test case is feasible, however, I will often build one in order to determine the answer. Creating a test case provides several benefits:
‍

• I learn something new that I know to be true. Getting information anywhere else, including from product documentation, only provides information that I can choose to believe is true. On more than one occasion, I have created test cases which demonstrated that certain documentation had errors (or that the software had bugs).
  ‍
• Gaining new information by creating a test case makes it something that I am much more likely to retain when compared to reading the same information in product documentation, or in a white paper.
  ‍
• Having the test case allows me to present information to others in a very concrete fashion that they can then use to do their own testing and verification.
  ‍
• Sometimes when creating a test case, I will learn a new method for performing some action that is applicable to my work.

Test cases are certainly not applicable for every situation. They are quite often useful when preparing for a certification in a programming language such as SQL, PL/SQL, Java, and so forth. By contrast, the most recent exam I took was Oracle Database Foundations, which had almost no opportunities for making one.

Test cases seldom apply to memorization-based questions. This would be things like knowing the different types of indexes available in Oracle, as well as the best uses for each. A test case is most useful if you need to be able to determine the results of issuing commands or actions like:

• What happens when I issue X command?
• Is it possible to perform X action?
• What are the steps required to perform X activity?

When creating a test case to answer a specific question, ideally you should keep it as simple as possible. A complicated test case is likely to introduce variables that can make the results invalid. It is also better to start with something you know to be true and work from there to answer an unknown. Below is an example of a PL/SQL test case I created recently. The code itself is not really important and is used simply as an example of the process.

A forum post asked if it was possible to nest a function inside a PL/SQL block. I seldom use this technique, because my development style makes use of packages, which limits the utility of nested subprograms. I thought the answer to his question was likely "no," but I decided a test case was warranted.

First I created a very simple nested procedure, which I knew would work. Even if you do not write PL/SQL, it should be reasonably clear that the below code is very simplistic to prevent any ambiguities.

DECLARE

v_val    NUMBER;

PROCEDURE nest_proc(p_val  OUT  NUMBER)

IS

BEGIN

p_val := 1;

END nest_proc;

BEGIN

nest_proc(v_val);

DBMS_OUTPUT.PUT_LINE('v_val = ' || v_val);

END;

v_val = 1

To test the poster's question, I transformed the nested procedure into a nested function.

DECLARE

v_val    NUMBER;

FUNCTION nest_func

RETURN NUMBER

IS

BEGIN

RETURN 1;

END nest_func;

BEGIN

v_val := nest_func;

DBMS_OUTPUT.PUT_LINE('v_val = ' || v_val);

END;

v_val = 1

It turns out that my initial guess was wrong. Functions can be nested and the test case demonstrated exactly how to do so. I learned something new and was able to provide a positive answer in the forum thread.

The time required to create the test case was reasonably close to what I would have spent locating the information in Oracle's documentation. The next time you are uncertain about how something works, give some thought to building a test case to answer your question conclusively.