I have tried the forum search but could not find a suitable topic for this. If there has been one before, please feel free to refer to it…
When we create or revise test cases, we are again and again faced with the challenge that we want to run a test case up to a certain point (eg. a breakpoint or a failed step) and then continue working on the test case from that point. However, we have not yet found a way to run the test to a breakpoint and then continue recording / capturing objects at that point. Does Katalon already offer this possibility, if so how, or is the feature already on the roadmap?
1 Like
You have both Katalon Recorder and Katalon Studio in your heading. Those are two separate applications. Are you using Katalon Recorder or the Web Recorder of Katalon Studio? What is the version number of the application you are using? That will help us to know which application you are using.
you are asking about the Katalon Studio Record web. or the Katalon Recorder browser plugin?
@bharathi.a
grylion54 already asked exactly the same.
are you an echo or a kudos hunter?
Oh, sorry I meant the web recording / object capturing tool within Katalon Studio 8.6.8. Thought Katalon recorder was this tool.
I have never heard of such feature in the Record Web function.
I just guess, no.
I personally do not use the Record Web tool often; but sometimes yes. When I use the tool, I use it to create a draft of Test Case source codes and a set of Test Objects to save time and efforts.
I launch the tool. I go though the couse of interactions with web browser from the 1st step until the end to record the script and test objects. I save them into disk. Then I will quit the tool. I would never launch the tool again.
I will manually edit the source of generated Test Case script in the Script mode and refactor them (=improve them + correct mistakes). I would read the generated Groovy source code. I would rewrite it to modularize it better. Sometimes I would split a Groovy source file into multiple files as module for beter code reusability.
I would manually refactor the generated Test Objects as well. I will add sub folders by web pages. I will move the generated Test Objects into the sub folders so that they are grouped semantically well-structured. I will rename the Test Objects for better names (auto-generated names are sometimes horrible). I will change the locator (XPath or CSS Selector) if appropriate. I will remove unnecessary Test Objects, as the tool generates a lot of garbage Test Objects.
I will do those move/rename/edit actions manually without tools support.
I suppose this is the way the developers of the tool assumed how users to use it. It is designed to record and playback but no more. It is not designed as sophisticated as you, @Testinator-X, want.
1 Like
Thank you very much for the detailed explanation of your working method. We too often use the recorder to create a first draft and then refine the code and objects in repository manually. Thats fine and works for us also.
Still, it would be useful for us (and I’m sure also for many other users) to be able to run an existing one automatically up to a certain point and then continue recording or capturing more objects at that point. So you could turn at one point to write a TestCase for another workflow. E.g. If we have a test that uses the “Discard Changes” dialog "Do you want to save or discard the changes? The “Discard” button is already in the repository. The “Save” button, on the other hand, is not. We also don’t have a test case for the “Save” case yet. To get to the dialog, however, many clicks are required beforehand, which the user has to perform manually in order to capture the required “Save” button to be able to add the object to the repository. It would be good if you could let the user run the same test up to the dialog and then continue the recording / object capturing there, so that the draft for the “Save” function can be created more easily. Wouldn’t it be good to be able to assist the user with this repetitive workflow by allowing them to run the working test up to the dialog and then continue recording/object capping from that point? The draft for the “Save” function could be created much easier this way.
The same applies to checking why a test case fails and possibly correcting a test case because once again an object from the repository can no longer be found due to some further development of our application. Execute test up to point X - interrupt test, check if the needed object is still there but cannot be found/identified anymore, (highlight of the respective object is not possible on the website anymore) find and correct the needed object (highlight on the website is possible again), add the corrected object to the repository and add the corrected object to the step. Done. Wouldn’t that be great?
If the function doesn’t exist yet, okay, so be it.
Q: Should the developers still regularly ask themselves whether the tool is good as it is, or whether it can be made even better? A: Always!
Q: Should developers of the tool ask themselves if the problem we mentioned is a way to improve the tool? Should you ask yourself if the problem we describe is an enrichment or absolute nonsense? A Maybe.
Q: Should the developers of their tool justify their decision if they don’t implement it? A: Would be nice to understand how it came to this decision, but whether they actually do it or not is also totally up to them.
Since KS is run on Eclipse, then how about using the F keys, like we used to in Visual Basic. I would try it, but on my home version (v 7.2), breakpoints are not available in the free version–it is an Enterprise feature.
But if you run the test to stop it at a breakpoint you can’t use the recorder with all its features. (Or I haven’t discovered this feature yet). There should be the possibility to debug and capture objects at the same time.
@Elly_Tran Can you ask your Team about the BreakPoint and what is and is not doable when you stop on it? Is there a document that @Testinator-X can review to give insight on what he can do.
When we used it in Visual Basic, you were “limited” to the specific line you stopped on and could not modify the code or the Debugger would stop/shut down. However, you could review all the variables’ values at the breakpoint. If you had multiple breakpoints, you could hit F5, F6 or F8 (Step Into, Step Over or Run To Next) and the Debugger would move to the next appropriate position or next breakpoint. Has the service improved since then?
@Elly_Tran The issue for me is not the debugger functionality per se but that I can use the recorder functionality even when the test is running.
What I want to achieve is:
- select an entry in the manual mode.
- tell Katalon: open the recorder and run to there. (It would be luxury, if this would work also in Debug mode).
- stop the playback at this point and allow to record/continue manually at this point if needed. (And at the end overwrite the original test or save it as a new test).
Hi,
Thank you so much for letting me know. I will ask my team and back to you guys soon.
Hi,
I would like to suggest this feature to you: Debug: Run selected steps: Execute only one or many selected steps. You can select multiple steps using either Ctrl or Shift key.
Doc ref: Record web utility in Katalon Studio | Katalon Docs. Let me know if any more. Thank you!
2 Likes
