Toad World® Forums

Don't re-activate inactive test cases


#1

For procedures that take a long time to run (2+ mins each), I keep inactivating test cases that have passed with the given dataset. Then I add another test case or outcome. But each time I do, all the test cases are re-activated. So I have to remember to inactivate them again using Edit Test Definition.

I’d like:

  1. Inactivate test cases to remain inactive.

  2. The ability in Edit Test Definition to see and modify the Active flag in the test cases list display.

  3. The ability to quickly deactivate test cases in the Append Test Cases window, since this is where I spend much of my time.

I’ve attached screenshots of the windows where I want to quickly inactivate test cases, in case the names weren’t clear.

Thanks,

Stew

qc4o - append test cases.jpeg

qct4o - edit test definition.jpeg


#2

Hey Stew,

Well, I read your previous post in the Datasets forum but couldn’t quite wrap my head around what you need at the moment (too busy getting the commercial version ready).

This one is a bit easier to tackle.

First of all, good catch on auto-activation. I will fine tune that logic (tho not for the Feb release).

But I have better news: in the commercial release, you will be able to run just a single test case at a time or single unit test, without running all others!

Soon, we will let you highlight a subset and run just those. But for now, you can run just the TC of interest without activating/deactivating.

Does that help?

SF


#3

Do everything possible to make your test cases run quickly. It is hard to emphasize this too much. If it runs quickly, developers are much more prone to run the test and find the bugs quickly, rather than wait until the end of the day or the end of the week. The xtreme programmers idea of test a lot code a lot works very well, to do that you must have fast tests.

All of of our tests are engineered to run on small datasets - we are testing that the code does the right thing, not that it does it quickly - speed is nice, but it must work first.

for oltp style stored procs, this is no problem - we create our own data in a setup call and test the results.

for larger batch style queries if there is no other way, we add an optional (default null or % or whatever )parameter to the signature and append an extra AND … to each where clause in the stored proc. Then the batch job can go through the all the motions just on a handful of rows.


#4

Steven,

Glad to help debug the beta! Good to hear the commercial version will let you run a single test. I thought the beta was for the commercial version, so I’m surprised to hear about a commercial feature that we didn’t see already?

Nick,

Good suggestion to make unit tests that run quickly; you’re absolutely right! It wasn’t clear to me if you were telling me to write tests that run faster or hinting to Steven that QCT4O runs tests slowly. I’ve actually been surprised at how long it takes QCT4O to run my set of tests. The same test set that QCT4O runs in 11:30 minutes takes 10:31 minutes using utPLSQL. That’s with QCT4O pre-generating the test package.

Unfortunately my tests have to compare record counts between different datasets so I can’t speed up the tests by putting a limit on records; that would defeat the purpose!


#5

Stew, yes, we were moving really quickly through that initial beta cycle. Sorry about that! We plan to move to “perpetual beta” just like Toad, probably set that up within the next couple of months.

Performance: we are definitely going to be paying some focused attnetion on tuning execution of Code Tester in the coming months. Our biggest concern is performance over a WAN and VPN.

The difference in test performance: very interesting. Are you sure you are running all the same tests? I would love to see both test packages to try to find the differences.

Many thanks!
SF