Tosca > Steering Parameter > FireEvent

A very useful item in your Tosca toolkit is the steering parameter 'FireEvent' (the green 'cubes' in the Properties tab of ModuleAttributes). By default FireEvent has the value 'change', but sometimes other 'events' are needed to have the website respond as desired. Recently I ran into a checkbox the checking of which changed an OK-button from disabled to enabled. The default 'change' value checked the checkbox without enabling the OK-button. All it took was to set FireEvent of the checkbox ModuleAttribute to the value 'click' and the OK-button was enabled.

In the case of multiple FireEvents separate them with a semi-colon. For example: 'change;blur'.

The possible values of FireEvent are:

• onchange
• onclick
• ondblclick
• onblur
• onfocus
• onmousedown
• onmouseup
• onmouseover
• onmouseout
• onsubmit
• onreset
• onpropertychange

Pay note: in Tosca the values given to the FireEvent steering parameter should be WITHOUT the 'on'-prefix.

Tosca > Ports required by the Tosca components

Several times during the building of our TA framework I've been temporarily blocked when having to find out which ports/traffic need to be allowed between Tosca components. Turns out there is a great Tosca page for it:

Search for: PORTS REQUIRED BY TOSCA COMPONENTS

https://support.tricentis.com/community/manuals_detail.do?sysparm_document_key=u_webhelp,425d827d379dd640406642f643990eea

Tosca DUH! moment: April

Test Automation is - in the end - software development. Everyone who has ever dabbled in software development is familiar with being stuck on things that in the end turned out to be very trivial and make you feel like: DUH!. I'll be logging my Tosca DUH! moments in this post. It'll be good as therapy in any case, and seeing all these items listed under each other might provide me with some insights.

• Fed 'Buffername' instead of '{B[Buffername]}' to the parameter field of a ReusableTeststepBlock.
• Circumstance: the buffername was used in a query, which - with the wrong data - produced zero results and this resulted in a confusing 'invalid column name' error.
• Mitigation: not easy. There is no easy debug mode in Tosca to quickly see all PL or B values. Will have to be mindful of this.
• If SteeringParameter FireEvent=change doesn't do the job check if other 'events' are being listened to and set the FireEvent parameter to them / add the FireEvent to them.
• If you want to have {Click} position the mouse-pointer somewhere else than in the middle: write a customization where you override the 'ActionPointer' property.;
• TypeReference.IsAssignableFrom(Type c)
• is TRUE if the TypeReference can be assigned to an instance of Type c
• Shorthand notation to define an IEnumerable object:
• IEnumerable<Obj> collection = new[] {Obj1, Obj2, Obj3, etc.}

Tosca > {DATE} or {DATE[][][]} function

For some reason I ALWAYS forget what the correct syntax is with this function. So hereby a post to forever remember:

First: a good search term in the Tosca documentation:
DATE AND TIME EXPRESSIONS

Syntax:
{<EXPRESSION>[<Basedate>][<Offset>][<Format>]}

In normal human readable:
{DATE[basedate][offset][format]}

Key-letters for specifying the format:

d	days
M	months
y	years
h	hours
m	minutes
s	seconds

Visual Studio & Git & BitBucket: how to get started

I am not very knowledgeable when it comes to version control systems (something I really have to develop myself further in), but luckily many tools work pretty well out of the box. A very simple way to get started with VCS is to use Visual Studio's built-in-Git with BitBucket.

HOW TO:

• Create a new empty repository in BitBucket
• Create your to-be-version-controlled project in Visual Studio
• Add the project to version control and choose 'Git'
• Go to Team Explorer
• Go to 'Changes'
• Type 'initial commit' in the textbox
• Click to the 'Commit' button
• Choose 'Commit and push'
• VS will give an error message that no remote repository is linked to the project
• In that same error-message-screen will be a textbox where you can add the url of the remote repo.
• Copy-paste there the URL to your BitBucket repo and...
• Done!

Dabbling in TTT > Powershell script to assist with development/deployment

When working on SETs/Adapter customizations/Addins one of the very annoying activities is 'deploying' your .dll to Tosca after building it:

• Find the directory where the newly built .dll was placed
• Copy the newly built .dll to %TRICENTIS_HOME%\Automation\Framework
• "Oh shit, forgot to 'End Process' the 'Tricentis.Automation.Agent.exe'"
• End Process@Tricentis.Automation.Agent.exe
• Re-find the directory where the newly built .dll was placed
• Finally copy the newly built .dll to %TRICENTIS_HOME\Automation\Framework
• In the case of an Addin-deploy we even need to add killing the actual Tosca Commander client to this checklist.

Let's write a powershell script which takes care of all that. We'll have to write two scripts. One for SET/CustomAdapter deploys and one for Addin deploys. Because of the aforementioned reasons

The SET/CA deploy script is easily done... [added:] actually it was not so easily done. The script posted earlier would often generate error message because the copy-item would be called before the old .dll would truly be released. With the help of stackoverflow we modified the script to be more robust:

#IsFileLocked was literally copied from Stackoverflow

function IsFileLocked([string]$filePath){
    Rename-Item $filePath $filePath -ErrorVariable errs -ErrorAction SilentlyContinue
    return ($errs.Count -ne 0)
}
$newFile = "[fullpath of new .dll]"
$targetDirectory = "C:\Program Files (x86)\TRICENTIS\TOSCA Testsuite\Automation\Framework"
$TAA_Id = Get-Process -Name "Tricentis.Automation.Agent" -ErrorAction SilentlyContinue
if($TAA_Id)
{
Stop-Process -inputobject $TAA_Id
Wait-Process -inputobject $TAA_Id
}
Do
{
Start-sleep -m 500
} While(IsFileLocked $newFile)
Copy-Item $newFile $targetDirectory -Force

It bugs me that the above script has a hard 500ms wait in it, but I couldn't get the script to consistently work without it and won't waste time on half a second. The only caveat here is that you have to run Powershell in administrator mode. A quick Google showed it would be possible to make the script self-elevating but that's an exercise for another time. The above very simple script seemed to work fine and is a real time saver.

After updating the SETDeploy the AddinDeploy becomes trivial:
function IsFileLocked([string]$filePath){
    Rename-Item $filePath $filePath -ErrorVariable errs -ErrorAction SilentlyContinue
    return ($errs.Count -ne 0)
}
$newFile = "[fullpath new .dll]"
$targetDirectory = "C:\Program Files (x86)\TRICENTIS\TOSCA Testsuite\ToscaCommander\Addins"
$TAA_Id = Get-Process -Name "TOSCACommander" -ErrorAction SilentlyContinue
if($TAA_Id)
{
Stop-Process -inputobject $TAA_Id
Wait-Process -inputobject $TAA_Id
}
Do
{
Start-sleep -m 500
} While(IsFileLocked $newFile)
Copy-Item $newFile $targetDirectory -Force
Start-Process "C:\Program Files (x86)\TRICENTIS\TOSCA Testsuite\ToscaCommander\TOSCACommander.exe"

Tosca > Ideas to manage your artefacts

A fully developed TA framework based on Tosca can potentially have many artefacts, such as:

• The Tosca version
• The Tosca repository (One would almost forget!)
• Tosca customizations in the form of .dll-s:
• Special Execution Tasks (SETs)
• Adapter Customizations
• Add-ins
• ODBC drivers for DB access
• Tosca (.tcs) scripts to run Tosca via the commandline
• PowerShell scripts which call the .tcs scripts

I am currently faced with the challenge of getting several scrum teams to start using a Tosca TA framework on a daily basis. This means that the framework userbase will increase from 2-4 TA project members which are intimately familiar with the product to 10-20 testers and devs which aren't. And, oh yeah, somewhere amidst all that a CI/CD pipeline will also be set up which will run Tosca scripts as part of its automated testing suite.

We clearly need:

• A way to 'push' artefact updates to the (vastly increased) userbase
• Version control on the artefacts

After a bit of research we have decided to go with the "Chocolatey, NuGet, Artifactory, OneGet" stack of technologies to try and implement this. I have next to no experience with these technologies so this should be interesting.

(Note: The technology of our company is predominantly Microsoft based (Windows desktops, Windows servers, C# .NET applications) which has been taken into account when choosing these tools.)

Update:
Ok, let's see if we can get a proof of concept going. We're going with:

• A powershell script which calls an...
• Executable which in turn calls
• UniversalGreeter.dll which reads the target of its greeting from a
• universalgreeter.config file which contains the word 'World'

Goal #1

• Squeeze all that in one NuGet (using OneGet?)
• Commit the NuGet to Artifactory
• Pull the NuGet from Artifactory for a local install
• I have as yet no idea where Chocolately comes into play here

Goal #2

• Same as Goal #1 but with added version history
• Including being able to install olders version (a rollback scenario)