Forum Discussion
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...
- cunderw8 years agoCommunity Hero
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.
- AlexKaras8 years agoChampion Level 3
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-QA8 years agoFrequent Contributor
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.
Related Content
Recent Discussions
- 11 hours ago