Thursday, 2 March 2017

100 Day Deep Work - Day 2: Comparing Expected and Actual Values



Thoughts, discoveries and blockers from Day 2, posted a bit late as I was having some computer issues last night, got to love system updates!

The plan yesterday was to study iterating over multiple elements of a page using Selenium, such as sets of links or dropdown items. It’s one of those problems where I’ve solved it before but I always felt it was in a crude way. However, I got entirely side tracked by the idea of identifying the Div section in which a set of links, for example, might appear instead of the individual links. That feel more like a general UI based test, whereas checking for individual links is more a unit test.

It all depends on the purpose of the test of course, but at the UI level we really should be looking at user journeys and workflow, how the user traverses the site’s functionality to achieve a specific goal. Not so much the assertion of individual elements just for the sake of it, that’s more of a unit level test. I feel that assertions of elements on the page should be limited to ensuring those that are needed for the test are in place. I’ve seen a pattern of testing for first and last items to load on the page or just waiting for a document.Readystate is complete (1, 2).

Turning back to the main thrust of yesterday, here’s example code for a pattern of declaring what we’re looking for then asserting we found it.

        public static void CheckWeHitTheRightPage()
        {            var homepageWelcomeMessage = Driver.Instance.FindElement(By.CssSelector("div.zone.zone-content > h1")).Text;
            var expectedHomePageText = "Welcome to the Website";
             if (homepageWelcomeMessage == expectedHomePageText)
            {                Console.WriteLine("As expected, I saw '" + homepageWelcomeMessage + "' on the home page.");
            }            else            {                Console.WriteLine("I could NOT confirm we're on the Home Page");
                var homePageException = $"I expected ' {expectedHomePageText} ', but I saw ' { homepageWelcomeMessage } '.";
                TakeScreenshot.SaveScreenshot();
                throw new Exception(homePageException);
            }         }

There’s some extra bits in there like capturing a screen shot but you’ll get the idea. I’m was quite happy with the pattern until I tried it to find a Div, as mentioned above. The below code does NOT work in the context I was trying it. When Writeline outputs what was returned for the value of topNavClassName it comes back as OpenQA.Selenium.Firefox.FirefoxWebElement each time. Clearly comparing that with a

        public static void validateTopBarNavigationIsPresent()
        {             var expectedTopNavClassName = "container-fluid";
             // Find the navigation element container to check it loaded            var topNavClassName = Driver.Instance.FindElement(By.ClassName("container-fluid")).ToString();
                 Console.WriteLine($"The variable topNavClassName contains the value: {topNavClassName}");
             // OR perhaps it's better to find it this way?            //IJavaScriptExecutor js = Driver.Instance as IJavaScriptExecutor;            //string topNavClassHTML = (string)js.ExecuteScript("return arguments[0].innerHTML;", expectedTopNavClassName);            //Console.WriteLine($"The variable url contains the value {topNavClassHTML}");             if (topNavClassName == expectedTopNavClassName)
            {                Console.WriteLine($"I found the main navigation Div by its Class Name: {topNavClassName}");
            }            else            {                Console.WriteLine("The main navigation Div was NOT located on the page");
                var topBarNavigationException = $"I expected to find the main navigation Div of 'container-fluid', but instead I got {topNavClassName}";
                TakeScreenshot.SaveScreenshot();
                throw new Exception(topBarNavigationException);
            }        }

I also investigated if pulling the Class from the HTML might be a way forward (see the commented out part of the code) but I hit the same issue. That issue being IWebElement and a String can’t be compared so we have to tack on the ToString() on the end of the line where we find the Class name. That way it’ll be accepted and the solution can be built. But still, it comes back as OpenQA.Selenium.Firefox.FirefoxWebElement each time.

We can change the condition in the If statement from if (topNavClassName == expectedTopNavClassName) to if (topNavClassName != null) and we get a result. The issue is I want to know what topNavClassName actually contains. Or do I? If I change the name of the class is does fail, such as to ClassName("container-fluidsss"). So maybe that’s enough. It would be more reassuring to know what’s in there. Frustrating.

Hmm, well onto day 3!

------------------------------------------------------------------
Day 1: http://cyreath.blogspot.co.uk/2017/02/100-day-deep-work-day-1-c-namespaces.html
Day 0: http://cyreath.blogspot.co.uk/2017/02/100-day-deep-work-day-0-learning-plan.html
------------------------------------------------------------------

Links and References

0 comments: