Hi,
Miscellaneous Category contains Delay operaton. Does it help?
You can add a Delay for some fixed length of time this way:
https://support.smartbear.com/testcomplete/docs/keyword-testing/reference/misc/delay.html
If you were running this test manually, how would you know if the internal process had stopped or not?
While you can add a physical delay, I'd still aim towards finding something more dynamic.
So, this internal process. What does it do? Does it update an SQL table? Create a file? etc? As Marsha_R suggested, if you were doing this manually, how would you know the internal process is complete? Would you click on something, check a value, and then wait and repeat the process?
The reason why I'd not do a physical delay is two-fold:
1) The process may take LESS time on some iterations through the test than you have the delay set for which would mean that you would have an automation process sitting doing nothing for a time when it could be continuing the process.
2) The process may take MORE time on some iterations through the test than you have the delay set for which would mean that you could end up with an invalid test because you didn't wait long enough.
So, finding a dynamic way to check the process and determine if it's complete will minimize the idle time of your process while allowing for long potential delays by setting a maximum timeout.
Hello Robert,
I understand what you are saying and I wanted to avoid "empty" delays, I know they are not the best.
In this case, nothing changes in SQL. Nothing changes on screen either. No variable is populated. I am testing a Point Of Sale software and after a sale, we revert back to the "initial" menu (if it was changed). In my case, the menu/screen was not changing in this specific test.
I need to test the transaction total after I hit the Cashout button, but since the process is trying to set back the menus to default, when I check the total immediatly it is empty. And the total is not shown as a field, we "draw" it on a generic form, there is only one object name and it doesn't change once the total is populated.
I don't know if I explained it well, but I do understand your statement! We might rewrite parts of our application to be more Automation-friendly over time, because as it is right now, it is not always easy. We have forms that use a dynamic number, each time the software is launched, it'll receive a different form number - it was not hardcoded when it was build. So it is hard for me to even verify if an object is active.
Thanks for the help!
Logiv Having worked with a POS application myself in the past, when a transaction is completed, there HAS to be some data stored somewhere. :-) We had a journal that logged every transaction in detail that was "pushed" to SQL on a regular trigger. So, for us, when I was automating that application, after we'd complete the transaction, we'd check the SQL journal to see that the transaction pushed before we moved on. This was actually necessary in our test because at the end of the transaction we wanted to ensure that the data in SQL matched the transaction we tested (payment totals, item totals, tax totals) as we had discrepencies in the past between what was journaled and what the actual transaction was.
So, for your situation, there has to be some data stored somewhere at the end of the transaction that can be checked to indicate that the transaction has been completed. That's what I'd look for, even if it's an internal value that's not visible on screen.
Just my $0.02. :-)
