I’m attempting to create our own handler library using the SenseTalk Browser (similar to EPF’s native library provided) so that our handlers are easy to find/use/understand. We currently use the “highlight the script and handler together, right-click and select ‘Show Resource’, then use Control + F to locate the exact handler within the script” method, which is growing in impracticality.
Is there a way to utilize/activate the “More on this topic…” link button and link the handlers either a) directly to that handler within the script (which would be preferred), or b) link the “More on this topic…” button to a different location, such as a corresponding .md file in Git or a text file/library in Confluence, etc.?
That sounds like a great idea!
How do manage changes to the handler library you’ve been working on so that when you update a handler it doesn’t break code that already uses it, bh_eggy?
Kind regards,
Jerry
webbje, that is a great question!
Currently, we stick with “if you change a handler, you are responsible for updating all instances of this handler as needed” philosophy (which, hopefully, is already a part of the engineering culture/best practices). First, we would update the handler. Second, we would use the Search Bar (in the top-left corner of the Suite Window) to search for all instances of that handler, and hopefully we can “mass-update” all instances (which could result in a LOT of changes, depending on the handler use). The Search Bar also gives us the option to walk through each instance individually and decide if we want to update it or not. This method isn’t horrible and can be quite efficient, so I’m not sure the juice is worth the squeeze.
However, it would be pretty cool if there was another way, such as an “auto-update” option (that basically did the same thing above for you)? For example, what if there was an alert to the user that the handler had been changed and that the number of instances reached an instance max (i.e. "more than 10 instances of this handler, either by default or set by user in Preferences)? What if this alert was part of the Script Checker, which would notice the change to the handler, count all instances of handler and, if max has been reached, alert the user to check all other instances (and maybe gave the option to “update all”, etc.)?
I’m still not sure what can be done, but this is a great discussion!
Our work-around is that we check code that we’re working on into two Git repositories, one for the common code, and one for the Suite that tests the functional area that is being worked on.
We have 10-15 separate repositories of code for different UIs to systems that we test but each repository contains a docs folder, a framework folder (common code that is 100% stable and rarely updated), a lib folder (with the common code for the system area) and a tests folder (with non-library code in it that is specific to Use Cases). We use relative paths to call library functions from the common code folders . When work starts on a new Suite of tests, the developer populates the Framework folder with a copy of a stable branch of Framework and Library code from one Git repository, and from then on, any changes that are made to are done on this “fork” of common code.
We can pick out improvements at a later date generally - the code that is in the Framework folder is rock solid and only changes when a major platform change occurs (for example, a new version of the OS windowing system is released).
We’re kind of forced into this way of working because we have a lot of functionality to test - a galaxy of systems - and we want to follow a Don’t Repeat Yourself (DRY) model of not having to fix Eggplant script failures caused by a release/upgrade more than once. The better way of handling this would be to have a component or module based design construct in Eggplant SenseTalk so that libraries of code with clearly defined interfaces, pre-conditions, and post-conditions were supported by the language itself (compare with Java interfaces).
The lack of these is the single greatest barrier to using SenseTalk on large testing missions, in my humble opinion - it’s a fundamental design flaw with the product. Teams should be able to share libraries of code easily, but cannot.
We are able to share code fairly easily using Git and Eggplant. If another team wants to use our code, they set up their own repository and Suite in Eggplant. Then, they check out our repository (or only the suite they need) and add our suite as a helper suite in the Settings of their repo. From this point, our code can be called like any other code from anyone and Eggplant knows where to find it.
We also designate a single team in charge of each repository, including any shared repositories. The leaders of each repository are responsible for ensuring that “don’t re-write anything unless you have no other option” is a part of their teams’ culture/best practices. We also have very strong communication amongst Eggplant development teams, which is also a cornerstone of our engineering culture (pretty important stuff!).
Simple and works for our org, but one size does NOT fit all when it comes to Eggplant. 
In response to the original question, the “More on this topic…” link button was only designed to provide links out to the Eggplant documentation. Allowing it to link to other things from your custom snippets is an interesting idea, but not supported right now.
Regarding the lack of support in SenseTalk for clearly defined interfaces that webbje pointed out, it’s true that there is no direct support for that sort of formal construct. Using objects and SenseTalk’s helpers I think it might be possible to put together a reasonable approximation, though, that would allow for defining an “interface” and could check for conformance to that interface. It’s just an idea that would need some work to flesh out, though.
2 Likes
The way that I have addressed this in the interim is to create verbose descriptions in my snippets. You can see and example of my SuiteSnippets.rtf and my Handler Garage here: GitHub - keysight-eggplant/HealthcareSolutions
2 Likes
@DaveHester , I think “Fred” is my favorite:
Thank you!
2 Likes