Hello
Consider the following:
initFunc.js - this file parses an excel for all the test data ( 50 variables).
I would like all the other scripts, tests, suites, etc. to access this file and use the variables.
Any "neat" suggestion?
Thank you very much.
Hagay
It’s mostly depends on how you are going to organize your frame work.
For me I keep most global variables in my project variables. At the beginning of test -run all variables are uploaded through script if already not there.
..you can use this
But test data I would keep in XL files and use DDT excel driver at each test to retrieve those. Sometimes test data could be duplicated but the way I organized have to live with it.
Hear what I mean variables are thing that common for project like database name, exe name, file path ..etc. Data means customer number , customer name, account number ..etc.
If you mention how you going to arrange your frame work in high level we could give a better answer...
The framework I'm currently developing parses the data from the source into a property on a Script Extension runtime object. That data persists on that property across projects as long as the TestComplete sesssion is still running. Until I shut down TestComplete or change the value, I ALWAYS have that data available. Some of this information are configuration variables (SQLServerName, current test run ID, etc), some of the information is the list of test cases/test steps to execute for the test run (built into JSON data).
I also have been playing around with the Options part of script extensions where you can configure something that persists even after TestComplete has closed and re-opened. I'm using this for some of the stuff that changes rarely (like the aforementioned SQL Server name, etc) that I can configure once and then never again.
I've, in the past, created a whole script unit in the project and just called it "globalvars" and made sure I included that in every script unit everywhere. I don't like this quite so much because it's a pain in the butt to always make sure you add the "uses" or "USEUNIT" clause at the beginning of your code... additionally, this doesn't help much for keyword tests.
As NisHera mentioned, there are advantages and disadvantages to the different ways of doing things. It all depends on how you're planning on using them and how you are constructing the rest of your test project/framework.
Thank you guys:
Following NisHera request, here is the structure of my framework.
Every driver script has the following:
- Requires libs
- Reads config.js
- Parses data from Excel into variables to be used in the script
/**
* require
*/
var spLib = require("spLib");
.........
..........
/**
* READING FROM CONFIG FILE
*/
var envConfig = require("config_env");
var urlAUT = envConfig.url;
var environment = envConfig.environmentName;
......
......
/**
* READING EXCEL
*/
var testdataArray = [];
var myDataSet = spUtils.ReadFromExcel(datafilefromconfig, datasheetfromconfig, sPath, function(data){return data;});
var dataToSplit = myDataSet.split(",");
for (i in dataToSplit)
{
testdataArray.push(dataToSplit[i]);
}
var count = dataToSplit.length;
var adminName= dataToSplit[0];
......
......
I would like for these variables that I create from reading the excel sheet, to be globally available to any driver script. In other words - I want to eliminate the need to keep reading the excel file everytime I create a driver script.
So, much like we export (module.exports) our functions making them available to all AND require (require) them from a calling function -- I would like to be able to make a variable "global" and have the ability to call it from any script.
I hope this makes sense.
Thank you
I am probably lacking some information regarding implementing and utilizing the extension.
I followed the instructions online, I can see the extension via the extension dialog box, however I am not able to use it.
Any suggestions?
Extensions are a way to add functionality into TestComplete in a number of different ways. What I have been working with most often has been RunTime Objects. Basically, if you are writing script code or a Keyword test, a Runtime object from a script extension is utilized much like the built in objects like aqUtils or aqString. There are methods and properties that you can call within your test project that will do certain things during runtime.
https://support.smartbear.com/testcomplete/docs/working-with/extending/script/creating/objects/index.html
So... if you want to create a function, variable, method, object, etc., that you want to have available globally throughout your project, you can do so with a Runtime Object script extension. As an example, a script extension that I use in some of my personal work has variables and methods used for executing SQL queries via a runtime object. Some of the properties of that extension are things like the SQL Servername, the database name, etc. Using that extension (called SQLUtilities), I can write code like:
//The following function can be included in any project but it only ever needs to be run the first time to set up the desired settings
function SQLOptions(){
SQLUtilities.SetSQLOption = 'MSSQL'; //Can be either MSSQL or MYSQL_351
SQLUtilities.SetSQLSecurityType = 'INTEGRATED'; //Can be either INTEGRATED or PROMPT
}
//Now, if I want to run an SQL query against my database, say I want to select a number of rows and log how many I got
function checkRowCount() {
var MyRows;
SQLUtilities.DatabaseName = 'MyDatabase';
SQLUtilities.SQLServerName = 'MyServer';
SQLUtilities.SQLUserName = 'myusername'; //This is not necessary since I'm using integrated security. Provided in example to allow for editing and adaptation
SQLUtilities.SQLPassWord = 'mypassword'; //This is not necessary since I'm using integrated security. Provided in example to allow for editing and adaptation
MyRows = SQLUtilities.ExecSQLQueryFromString('SELECT * from myTable');
Log.Message('We got ' + MyRows + ' back');
}
So, to answer your OP, you could create a Runtime Object script extension which would contain those global variables as read/write properties on your runtime object that you can then access from any script or test in any project.
