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.
You can read the following:
Thankyou Shenpeng, I’ve only had an initial look but this looks very promising. I really appreciate you reaching out to me on this so promptly.
Thanks @mmartin! I’ll check these out too - the advice Shenpeng offers is useful but wide of the mark in dealing with scaling up team size and using common code.
These coding standards from Mat are really very good. Thank you so much for pointing them out to me Michael.
Eggplant is a software testing tool, and its coding standards would typically be defined by the organization or development team using the tool.
@mmartin This is a great document. We’re just starting to compile ours and outside of the Eggplant Best Practices and the Eggplant DAI Style Guide, I’ve been thinking a lot about overall architecture. I’m trying to put together a Suite and Script structure based on the below to better organize and allow for more logical sharing of common functions across SUTs:
High-Level Architecture Overview
• Helper Suites (containing rarely-updated scripts)
• Test Suites (containing regularly updated scripts)
When it comes to images, it’s also important to use image collections that maintain their naming integrity down through the pool, especially where lots of variations on one image can exist (which is probably obvious):
Looking forward to fully fleshing it out, from top to bottom, and also getting some solid coding practice examples into the document as well. SenseTalk is very flexible and when your script base gets very big you want to minimize script errors as much as possible. Standards are one important way to do that, as is leaning away from that flexibility!
I think that’s a really good observation @chrisbryant , we are updating images from Windows Server 2008 to all versions up to the latest, we still have to test releases for Windows 2008 R2 though for the time being.
I’m not sure I understand the structure under Login though, is username a developer user name or is this a user role (and the images pertinent to that user role) in the SUT?
One of our challenges has been steering people towards adding Windows 11 images to existing helper scripts rather than creating entirely new ones because the 2008 R2 image wasn’t matched in their example. Another challenge - unrelated I guess - is actually that the desktop is configured so differently between early and later versions of Windows. This is where I feel that a component-based design approach to snippets would pay dividends if EPF could only support code re-use.
The “Login” here is a generic example, though we happen to have several logins across SUT that all have their own unique “functions”. We will re-use code - for example, I’ll have a script for just a login called (for example) “SUTLogin.script” that I call from the “SUTMain.script”:
// Section Highlight:
// SUTLogin - Call SUTLogin.script to login to the SUT w/credentials
Just place it on it’s own line. I have quite a few scripts like this.
I suspect snippets could be shared (many are on GitHub) by Eggplant to a point but they couldn’t share images for things like Windows, due to licensing. We’d have to supply those. Your point is valid and I see where you’re coming from now with that specific example. My image collections keep growing!