Toad World® Forums

Any plan for a "Creation test" API?


Most of the times we make similar test for some programs.
I was thinking in the possibility of a API like
test_create(procedure/function, entry_values_type_array, output_values_type_array).

Maybe for special cases the UI entry could be the one option but for most of the function testing an API like this could be very usefull.


We do have an API - check the documentation in the Appendix for ‘PL/SQL API to Quest Code Tester Features’

It sends the SUCCESS|FAILURE results as a string back to your program call, so I’m not sure it does exactly what you are asking for now.

When we start working on version 1.6 and get into Beta testing, be sure to ask for this again with any specific enhancements you would be looking for.


That API is only to run the tests.
My question was about an API, so we could programatly create the tests.
A pratical case: for one program we are migrating from an old system and people want to test if ALL the previous results (by the old tool) are the same using the new program.
We got the entry values and output values via a spreedshet and it would be very helpfull if we could create the tests by code.


This is a very interesting idea. You can certainly programmatically
perform imports of test definitions. Beyond that, it seems to me that
constructing a test definition via API would be incredibly cumbersome.
There is so much information to specify.


You can certainly programmatically perform imports of test definitions.
Do you mean via direct access to the tables?

As I told earlier the aim was to support a small portion of the tests (5% of the possible tests but that are used 60% of the time).

A way to import the test via the application using a formated text file could also solve that.


Would that be like going back to utPLSQL?


Just when I thought most people would change their habit from utPLSQL to Code Tester . Code Tester seems to work a lot simpler than utPLSQL. It might be helpful though to have an even more easy way of creating test cases. Especially the first couple (20 or so) test cases take some time to put into the repository. For the following cases the current user interface is more than helpful.



I like the way you think! Yes, it is not a question of whether or not we can expose an API that would let you do everything the UI does via backend program calls, but whether or not you can isolate a subset of simple, often created cases, and then simplify the creation of those.

Clearly, that is doable. Before I go further down that line, though, I would like to point out that we plan to make Quick Build extensible. That is, you can take an existing test definition and Save As a Quick Build template. I think that it is possible we could use this approach to help you, um, quickly build out common, oft-needed tests.

Now, having said that, to do the API we need several things:

  • A list of what the common cases are - Code Tester users could help LOTS here and I encourage to think about this and reply on the forum with your ideas.

  • Development cycles (bandwidth) to build this. Such cycles are tight. I am totally amazed that even in its extreme youth, Code Tester already has an ER list several years long!!!

On the other hand, writing backend code is much, much easier than building UIs, so this could move quickly. Hey, especially if we could find a way to have some of our users (PL/SQL-pros that you are) help us build the APIs!