This is because you have Child defined as a function, but you're calling it like a property.
menu.Parent.Child.Click();
// change that to
menu.Parent.Child().Click();
EDIT: Looks like tristaanogre already said that. lol
Correct that seems to have done it.
My next question, is why isn't other classes able to see these functions? The Code below works. However when exporting the class to another, it doesn't know what UserPrefs is
var Header = undefined;
var Main = {
UserPrefs: function() {
Header.menuMain.HoverMouse();
return Header.menuMain_UserPrefs;
}
}
function foo() {
Header = Aliases.browsers.pageDashboard_PhysOffice;
Main.UserPrefs().Click();
}
Navigation.cs
var Menu = require("Menu");
function foo()
{
Menu.Header = Aliases.browser.pageDashboard_PhysOffice;
Menu.Main.UserPrefs().Click();
}
We have a header at the top of almost every page, I am trying to make a common class which all pages can reference when trying to navigate.
Menu.Parent.Child.Click(); is what I am trying to create. Then I would create a single class which handles Navigation.
Hi,
Out of scope... Just wondering...
What is the reason for you to implement your test code the way that is not obvious even to you?
Why not to revert to old good set of functions within script units?
I think that I am missing something, but the only advantage of this approach is that 'developers do it this way'...
But will it be easy for you and those who will use and support your code later to understand and fix it? To fix it in a tight time frame when you have a manager staying behind your chair and wondering: "Well, we deployed a new build 15 minutes ago... What is the result of your tests run? Did tests find anything? Can you tell me something that may prevent further deploy to production?"
Another point: how easy will it be to port your code to another scripting language? Within the course of tests automation, you will create generic functions that will do generic things that are common to any web project (e.g. scroll the object into view, wait until the object is populated with data, download file, process login dialog, etc.) If you are not going to spend all your days with the current company for this given project, is there any good reason to put yourself in a position when you will need to create generic code for any new script language a-new instead of just adjusting its syntax?
And one more point: neither intellisense nor the navigational combo on top of the code editor window in TestComplete support display of internal properties and functions for the classes. This means that you will have to memorize or somehow else document what functionality exists in your test code. Will this simplify and speed-up new code creation?
And sorry for not been helpful on the topic...
So I can definitely speak to this and why using classes / objects are incredible useful for automation.
/**
* @class
*/
class posPartInfo {
/**
* @param {string} rLine - the line code for the part
* @param {string} rItem - the item / part number for the part
* @param {string} rQoh - the qoh of the part
* @param {string} rDesc - the description
* @param {string} rType - the type of the part (stock, nonstock)
*/
constructor(rExists, rLine, rItem, rQoh, rDesc,rType) {
this.Exists = rExists;
this.line = rLine == null ? "" : aqString.Trim(rLine);
this.item = rItem == null ? "" : aqString.Trim(rItem);
this.lineItem = this.line + "_" + this.item;
this.qoh = rQoh;
this.quantityOnHand = rQoh;
this.desc = rDesc == null ? "" : aqString.Trim(rDesc);
}
setQOH(q) {
//code to set the qoh
}
}
Doing it this way you can retrieve test data from a number of different data sources and create a consistent object work with your other utilities. So if you have a utility that adds a part to your invoice, all you need to do pass this single object to it regardless of where you got from.
Now say you need to be able to additional things with your part info, like calculate the expected tax on the item. Well just add it to your class, not the 5 different utilities for getting your information and boom, all tests have easy access for this.
Also, 'developers do it this way', exactly, and automation people are just that, we are also developers, we just don't write applications in the traditional sense.
Anywho, my two cents.
Novari-QA wrote:
Correct that seems to have done it.
My next question, is why isn't other classes able to see these functions? The Code below works. However when exporting the class to another, it doesn't know what UserPrefs isvar Header = undefined; var Main = { UserPrefs: function() { Header.menuMain.HoverMouse(); return Header.menuMain_UserPrefs; } } function foo() { Header = Aliases.browsers.pageDashboard_PhysOffice; Main.UserPrefs().Click(); }
Navigation.cs
var Menu = require("Menu"); function foo() { Menu.Header = Aliases.browser.pageDashboard_PhysOffice; Menu.Main.UserPrefs().Click(); }
We have a header at the top of almost every page, I am trying to make a common class which all pages can reference when trying to navigate.
Menu.Parent.Child.Click(); is what I am trying to create. Then I would create a single class which handles Navigation.
It depends upon how you are doing the modules.export and the requires calls. I have a "toy" project that I use to explore creating custom JavaScript classes and have them called across code units and, when implementing such a thing in TestComplete, there were some "hoops" I needed to jump through to get it to work properly.
Could you share the entire code units, complete with the exports calls and such?
Certainly
Foo function works, where abc function do not.
