Timeout problem with long running test case

[Dave Burns]

I'm running a test from the Eclipse plugin. It runs for a long time and I used to get a timeout error from the plugin itself so I set the timeout option to 0. Now though I get a different timeout error from my CF9 server - I don't have the exact text but it's always after 60 seconds and always mentions CFLOOP taking too long.

Some background: I have a single test case function that has a dataprovider set up. That data provider is a list of about 250 file names and executing those 250 versions of the test is what takes so long. I've resorted to a hack in my beforeTests() that takes the array and prunes it:

variables.testCaseFiles = variables.testCaseFiles.subList( 0, 80 );
// variables.testCaseFiles = variables.testCaseFiles.subList( 80, 160 );
// variables.testCaseFiles = variables.testCaseFiles.subList( 160, 247 );

Doing this keeps the test run under 60 seconds. I then go in and manually edit the code to choose the next subList and rerun - once for each subList. Obviously: YUCK.

The obvious question then is: is there a better way to handle this? I suppose I could set up multiple (in this case 3) test case functions visible to mxunit and set up a data provider array for each of those but that's still klunky and I need to handle the possibility that my overall list can grow or shrink depending on other factors.

db

[Bob Silverberg]

It sounds like CF itself is timing out after 60 seconds. Try adding a
<cfsetting requesttimeout="big_number_here" /> into your test case,
base test case, or application.cfc and see if that helps.

Bob

> --
> You received this message because you are subscribed to the Google Groups
> "mxunit" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/mxunit/-/_QXK4O0GKbkJ.
> To post to this group, send email to mxu...@googlegroups.com.
> To unsubscribe from this group, send email to
> mxunit+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mxunit?hl=en.

--
Bob Silverberg
www.silverwareconsulting.com

[Marc Esher]

What Bob said.

Although I gotta say, a long running test case is a huge smell to me.
It sounds to me like you're perhaps doing way too much with the test.

I know, I know... it's easy to armchair quarterback this kind of
thing. Still... possibly there's like one core thing you need to test,
and you can adequately test it without running it with all those
permutations?

Marc

[Dave Burns]

Marc - Each individual test runs in a split second. But I'm using a data provider to crank through the permutations. Don't know if that changes your view on it. I had a choice between writing code for one test or writing essentially the same code for >500 permutations. Seemed like a classic case for a data provider. I'll try the <cfsetting> idea and report back if it worked.

db

[Marc Esher]

It does make sense, but I wonder if there's a way to do it that
doesn't take so long. If each operation takes 1/10th of a second, I
wonder if you can speed that up so that each operation only takes a
fraction of that time, by testing it in a different way. For example,
if you're passing in file paths, presumably something reads that file,
*does something*, and then asserts on the results. Can you test that
*does something* part -- whatever it is -- without needing to go
through all these permutations? Or perhaps without needing to read all
these files?

If not, another approach is, instead of breaking your files into 3
groups based just on a number, how about grouping them logically? Can
you break down the files into groups that more clearly express the
intention of that group of files?

For example, when I test passwords, I might have a "passwords that
should fail" list, a "passwords that should pass" list, and a
"passwords that should pass but fail due to being in the usser's
history" list. (just thinkign out loud here). Maybe you can group your
files similarly?

Marc

>
>
> db
>
> --
> You received this message because you are subscribed to the Google Groups
> "mxunit" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/mxunit/-/CCDHw3biksQJ.