Object functions returning Object, Javascript doesn't understand the type.

[Novari-QA]

I have an object that holds multiple sub objects. These objects can be functions or objects. See example below.

var menu = {
  Parent: {
    Child: function() { 
      Aliases.browser.pageDashboard_PhysOffice.menuMain.HoverMouse(); 
      return Aliases.browser.pageDashboard_PhysOffice.menuMain_Main; 
    }
}

When trying to get the object above, javascript doesn't understand what I am trying to return. It doesn't crash, the code just won't work when trying to call methods based on the returned object. See below

function foo()
{
  menu.Parent.Child.Click();
}

However the code below will work:

var menu = {
  Parent: {
    Child: Aliases.browser.pageDashboard_PhysOffice.menuMain_Main; 
}

function foo() {
  Aliases.browser.pageDashboard_PhysOffice.menuMain.HoverMouse();
  menu.Parent.Child.Click();
}

Why is it that the function returning the value won't work, but the an object that equals the value will work.

[tristaanogre]

By "won't work" what happens? Are there error messages?  What behavior do you observe.

One thing that comes to mind is that "Child" in the menu.Parent object is not a property... it is a method because you have it declared as a function.  So, try the following:

function foo(){
   var myChild = menu.Parent.Child();
   myChild.Click();
}

[Novari-QA]

Well it is working now, I am not sure why. But i am not complaining.  If anyone thinks this method is silly please comment

[cunderw]

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

[Novari-QA]

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.

[AlexKaras]

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...

[cunderw]

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. 

[AlexKaras]

Hi,

> we are also developers, we just don't write applications in the traditional sense.

With the only small difference (as for me) that usually we are working 'post-factum', running our tests for the already existing functionality and usually do not have much time to spend to adjust our test code to work for the tested version of the application.

Thus, while I am absolutely not against object oriented programming, but because of the above mentioned reasons, personally I value code clarity, simplicity and how easy is to modify the already existing code, I value these things higher than nice polished duplication-free design.

The best approach, is, as usual, somewhere in the middle 🙂

[Novari-QA]

@AlexKarasNormally I would agree, if I was only here temporarily or building upon an existing framework, yes I agree. However, I work here full time and I am by myself in the QA Team on this project, starting from scratch. I am trying to find a method in which non-developers can create test cases with ease. My current solution sounds great on paper, however, I am more than able to communicate with anyone who has time to discuss what I am doing wrong and why.

[cunderw]

Yeah, ultimately whatever works for you and your team is the best approach. That said, I feel some object oriented automation scripts provide better clarity in the code just by not having duplicated code. You know that if you need to change the way something is done in your tests there is only one spot to do the update and everything works again. I would hate to have to track down X number of use cases to make a simple change. To me that's not an easy way to modify code. Just my opinion, again if you're approach works, then it's a good approach 🙂