There isn't, as far as I know, a way of determining, from a function/method/procedure what other functions/methods/procedures are doing the calling.
There isn't, as far as I know, a way of determining, from a function/method/procedure what other functions/methods/procedures are doing the calling.
Thank you Robert. Your articles really helped me get started with TestComplete and gain a better understanding of test automation.
Do you have recommendations on how to keep track of all these functions or at least ensure that when you make changes to one function (e.g. changes in name and parameters), all the other functions/keyword tests that are dependent to it would be updated?
Or is this a valid concern? Did you run into this sort of trouble before?
Well, first of all, if I can at ALL avoid it, I never rename a method/function/procedure if it has been used at least once. That's just asking for trouble. Instead, I make sure I give it a good name to start with that is named in such a way as to reflect what it does. "executeSQLQuery" does exactly that, nothing else. If I need to do something different, I don't change the function, I create a new function. If they are similar enough, though, what I might do is modify "executeSQLQuery" by adding, as you noted, additional parameters. For JavaScript and other languages, you can make parameters optional by applying a default value in the declaration.
function foo(requiredParam, optionalParam = "default"){
....
}
Specifically, I add these new optional parameters to the end of the function so that, if it's already in use somewhere, I don't need to make any modifications in the calling function to utilize the new parameter.
Recently, I needed to redo an entire method and deprecate it. I needed to move it to a different unit, change the name, add new parameters, etc. Now, if I had just done so and deleted the original, I have over 100+ test cases that I'd have to go through and modify and change just to get them to run. Instead, what I did is created the new method in the new unit with the new name and parameters and then modified the original one to just call the new one as a "wrapper", setting default parameter values etc. This allows me to just keep my code as is in all my old test cases and start using the new one in any new test cases. When I have the leisure to do so, I then go through and make the changes so that, some day, I can remove that old method.
Just some tips from my experience.
