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