Suggestions for TestComplete
Greetings,
after working with TestComplete for several years, I would like to post a few suggestions for the future development. Of course other users are most welcome to post their solutions for these issues and problems as well.
I'd like to point out, that our TC-Projects are quite large and are mainly (but not exclusivly) using the keyword-driven test-feature of TC, meaning that even routines and subroutines are written in k-tests, while traditional scripting is only used for tasks, that are done more efficiently this way or cannot (yet) be done using k-tests only.
My suggestions kind of reflect that so here we go:
1) Tree-Expand-Option for Keyword-driven Test Editor
The 'Project Explorer' and the 'Project Items View' support context menue options for expanding and collapsing the tree structure.
This would indeed be very helpful for the kwd-editor as well (,especialy since there is a TC-Bug, which randomly collapses the tree after confirming the properties of operations).
2) Renaming Keyword Tests
This is of course already possible, however: If a Keyword-Test is called within another (or better say: a dozen other) Keyword-Test(s), it/they will not recognize the renamed Keyword-Test and fail to execute it. Interestingly though, the 'Project Item View' doesn't seem to suffer this problem and it would be very helpful if normal K-Tests wouldn't either.
2-a) In addition it would be helpful if the Keyword-Test-Caller would be capable of handling changes in the parameter count of the called keyword-test, for example: If parameters are deleted the caller could just try to use the called k-test with the remaining parameters. On the other hand, if new parameters are added the caller could use the default values for the new parameters without discarding the old ones.
2-b) Independantly of 2-b) it would be really useful to have a list of K-Tests who call other K-Tests (and the other way around).
3) Variables and Parameters handling enhancements
3-a) A relatively new feature of TC is the possibility to copy & past parameters. The same feature would definitely help variable-lists as well.
3-b) Parameters kann be customly sorted, while only column-sorting is available for variables. Again the same feature would be helpful for variables.
3-c) There is a button in the Keyword-Test Code-Editor ("Edit Expression") for directly selecting and pasting available variables into the code line. A similar button for parameters would be very nice, since it is quite awkward seek them out by hand.
4) Clean orphaned mapping entrys in name-mapping-table-file
Quite self explaining. Over the years my name-mapping-file grew over 200MB causing a noticable performance impact while working with TC (and possibly running tests). I doubt, that the whole mapping is needed, since many parts of our tested software had to be remapped again and again over time, because of changes in the GUI. Now, a user-triggered function for cleaning entries, that are neither used in script-units nor in keyword-tests would help a lot here. It wouldn't be a problem, if such a function would take a while to run throught.
That's it for the moment.
Regards
after working with TestComplete for several years, I would like to post a few suggestions for the future development. Of course other users are most welcome to post their solutions for these issues and problems as well.
I'd like to point out, that our TC-Projects are quite large and are mainly (but not exclusivly) using the keyword-driven test-feature of TC, meaning that even routines and subroutines are written in k-tests, while traditional scripting is only used for tasks, that are done more efficiently this way or cannot (yet) be done using k-tests only.
My suggestions kind of reflect that so here we go:
1) Tree-Expand-Option for Keyword-driven Test Editor
The 'Project Explorer' and the 'Project Items View' support context menue options for expanding and collapsing the tree structure.
This would indeed be very helpful for the kwd-editor as well (,especialy since there is a TC-Bug, which randomly collapses the tree after confirming the properties of operations).
2) Renaming Keyword Tests
This is of course already possible, however: If a Keyword-Test is called within another (or better say: a dozen other) Keyword-Test(s), it/they will not recognize the renamed Keyword-Test and fail to execute it. Interestingly though, the 'Project Item View' doesn't seem to suffer this problem and it would be very helpful if normal K-Tests wouldn't either.
2-a) In addition it would be helpful if the Keyword-Test-Caller would be capable of handling changes in the parameter count of the called keyword-test, for example: If parameters are deleted the caller could just try to use the called k-test with the remaining parameters. On the other hand, if new parameters are added the caller could use the default values for the new parameters without discarding the old ones.
2-b) Independantly of 2-b) it would be really useful to have a list of K-Tests who call other K-Tests (and the other way around).
3) Variables and Parameters handling enhancements
3-a) A relatively new feature of TC is the possibility to copy & past parameters. The same feature would definitely help variable-lists as well.
3-b) Parameters kann be customly sorted, while only column-sorting is available for variables. Again the same feature would be helpful for variables.
3-c) There is a button in the Keyword-Test Code-Editor ("Edit Expression") for directly selecting and pasting available variables into the code line. A similar button for parameters would be very nice, since it is quite awkward seek them out by hand.
4) Clean orphaned mapping entrys in name-mapping-table-file
Quite self explaining. Over the years my name-mapping-file grew over 200MB causing a noticable performance impact while working with TC (and possibly running tests). I doubt, that the whole mapping is needed, since many parts of our tested software had to be remapped again and again over time, because of changes in the GUI. Now, a user-triggered function for cleaning entries, that are neither used in script-units nor in keyword-tests would help a lot here. It wouldn't be a problem, if such a function would take a while to run throught.
That's it for the moment.
Regards
