We’re programming in the large on the project I am managing with Sensetalk, and the scripts we’ve written test a complex Delphi application written nearly twenty years ago. Each developer owns a User Story that takes a different path through the application, but each uses common code we’ve written to handle Use Cases that are common to all scripts, such as logging into the application and handling events that occur (such as new notifications) each time a login occurs.
I can share the approach we use to making a function call “shared” and putting it into a common library, but you can probably already guess what we do.
The issue we have now is that we’ve uncovered corner cases where that common function for logging in has extensions to cover additional steps that (for example) only occur rarely, when a system administrator uses the function to log in. This would seem to be best handled by cloning the orginal shared function, adding extra code, and saving it in a seperate Suite rather than trying to update the function in common code and rolling it out to the whole team to test thoroughly for regressions, but that approach is very problematic, it results in two functions with the same name but different behaviour being included in a release of Eggplant tests.
If this were Java or Python, the problem would be managed using package import statements, scoping rules and local variable scopes, and coding to interface definitions, but SenseTalk has none of these - so to cut to the question, have you developed any model of how to handle this, perhaps by enforcing coding standards? If so we’d love to learn more because the issue is killing our test automation approach - it just isn’t scaling up to large teams of test developers.