0

The automation framework I'm working within has a method in the PageObject file to return a WebElement by its label text:

getSubTab : {
    value : function(value){
        return this.navTabs.filter((elem) => {
            return elem.getText().then((text) => {
                return text.toLowerCase() == value.toLowerCase();
            })
        }).first();
    }
},

and now the "actual" WebElement reference I want:

listingPerformanceSubTab : {
    get : function(){
        return this.getSubTab("listing performance");
    }
},

That being said, when I made a PR to refactor the code to remove that getSubTab method, and reference the example WebElement above using a CSS selector like this:

listingPerformanceSubTab : {
    get : function(){
        return element(by.css('a[ui-sref="listings.traffic"]'));
    }
},

it was rejected for unclear reasons.

Which method is better/faster? I would assume mine, right? Because it's cutting out that call to the getSubTab method.

In addition to that, the text labels for WebElements change more often than WebElement attributes, which is why we'd want to use that method of referencing.

Update: I did have a conversation with the rejector, and his reasoning was:

  1. he thinks i'm using an xPath referencing style.
  2. as i said above he said "this is how we've always done it"
  • Better meaning a faster/more efficient way to handle this particular scenario. I did have a conversation with the rejector, and his reasoning was: 1. he thinks i'm using an xPath referencing style. 2. as i said above he said "this is how we've always done it". – kevin May 25 at 18:41
  • 1
    You didn't say that above. If you're asking how you convince your colleague this is better, I'd suggest: prove it; run both and show that yours is (meaningfully) faster. Note also that there's value to consistency in terms of people being able to read, understand and compare the tests. – jonrsharpe May 25 at 18:48
  • Hmm, sorry about that. i could've sworn i included that bit about what he said in my OP. i agree with your point that there's value in consistency across bits of the source code, but i also feel that if we're going to have a "standard" way to accomplish a particular step within the framework, might as well make it the fastest/most efficient way, right ? – kevin May 25 at 18:52
  • 1
    No because fast and efficient is not your goal because run-time is not actually a problem. Remember the two hard problems in computing - naming and premature optimization. This is about premature optimization. When you make something more efficient is is usually a trade off of less readable and maintainable. If you didn't have a specific performance problem you were trying to address you are solving the wrong problem. – Michael Durrant May 26 at 10:42
  • Put another way - most of my test suites for for 10-30 minutes and the "processing overhead" of the test framework is a few seconds. So it's not a problem worth addressing given the negative effects on readability that usually ensure. Remember "efficient" is not valuable if not needed or an issue – Michael Durrant May 26 at 10:44
4

I would expect directly referencing it by a few milliseconds.

However premature optimization ('efficiency, performance') without a clear issue to address will 'fix' the wrong problem and lead to less readable and maintainable code, which is more important.

So 'faster today' will quickly lead to 'but slower 'tomorrow' (i.e. the next time a change is needed) and then also slower the following next time after that that a change is needed and...

So name it and then reference it using the name

Automation code is usually very simple code and issues such as this make little difference in performance.
Some of the the key things to actually spend your time focusing on are:

  • Are we using happy, sad and smoke tests ?
  • Are we using the Agile Testing Pyramid approach ?
  • Are we using a Page Object approach for UI testing ?
  • Are we using the Agile Testing Quadrants to plan tests ?
  • Are we working closely with the business to identify cases ?
  • Are we focusing on flaky and flapping tests (intermieduate failures) ?
  • Are we focus on a dependable dev-ops pipeline running in the cloud ?
  • Are we working closely with the business to avoid testing everything through the UI ?

Also you mention being told "it was rejected for unclear reasons" - well how can u "fix" that if you don't know what the reason is. Don't be intimidated. Make it clear that without a reason you will not know what to change and will likely change the wrong thing, degrading quality, not improving it. When something works "but is not efficient" you need to ask a bunch of questions about what efficiency and performance standard you need to meet. Again "most efficient" will lead to hard to maintain, change, enhance, etc. code.

1

Putting aside all the general test automation wisdom, in this specific scenario I would suggest it's not worth it.

Reasons

  • It is reverting back code to an specific case from an generalized Abtracted code.

  • I have found labels/text are actually more static over time compared to internal object properties.

In both cases ,definition of element is local inside the function which is not good as it should be a class variable in a given page object so that any method can reference it and if required it can be changed at one place which will reflect in all the functions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.