I'm getting an error that the block mapper has exceeded the maximum search time. My response is only 7 lines long and I only have 2 blocks in the root container. The first is an optional line (which is the first of the 7 lines) the second block is a pair of lines that is repeated 3 times in the response.
I have no idea why it is timing out. I added this response to the samples for this response map and it maps fine there.
1) What is the maximum search time set for your block map?
The default 60 second.
2) Are you certain this same map is used in your test case? In your test case, select the step with this response, look at the structure data view in plain text mode. There should be a mappingInfo node which tells you which response map is being used to map this step. Is it the same map as the one you attached?
Yes, it is using this response map.
3) Is the actual response identical to sample3?
Yes, I copied it straight from the response view. The first line of the response is actually an overflow from the command which is longer that the width of the window.
Your 'new' response map works fine in the response mapping window, but when I ran it, it came back withan expected punctuation token ****************************; Received Word Token mysql in block rows, line 0, col 0 (Number of * is approximate)
Can you turn on the heap status on? Go to Window->Preferences. On the General page, check the "Show heap status" checkbox.
After you enable this feature, you'll see the heap status information on the bottom of the iTest window. It tells you how much memory is being used. Next time you run your test case, can you tell me what the heap status looks like? I suspect that your test case is using most of the available memory so that mapping becomes really slow.
Yes - by default the terminal width is variable in iTest. You can set to a fixed width with a larger number for your session profile so that your command does not wrap and hence become part of the response.
I just did this (increaded the terminal width) and it works.
It would be much nicer if iTest "knew" that the command was not part of the response, and therefor did not try to response map it, no matter how many lines it is on.
If the sample maps fine in the response map editor, then there is something else going on.
1) What is the maximum search time set for your block map?
2) Are you certain this same map is used in your test case? In your test case, select the step with this response, look at the structure data view in plain text mode. There should be a mappingInfo node which tells you which response map is being used to map this step. Is it the same map as the one you attached?
3) Is the actual response identical to sample3?
On a side note, your response map looks good, but it is important to know that wildcards (allow token or line to be any content) is generally expensive. Although you can't avoid it with the kind of response you have, I've tweaked the map just a little bit to make it faster. Instead of taking 5 seconds to map on my computer, now it maps instantaneously. I just removed a couple of places that you're using wildcard based on the three samples you provided. Of course you should double check that my changes will work for all the responses you're using with this map.
Can you post your response map so that we can take a look?
