Which is faster: creating a method to a web element by label text, or directly the element via a UI?



  • 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"


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



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2