2

In JUnit's assertions you have an optional parameter which allows you to to display it when the assertion fails, to allow the tester know what actually failed from a human-friendly perspective.

Is there some equivalent in Selenium WebDriverWait's wait methods, or perhaps some kind of workaround for it? Try/catch would do the trick but seems quite messy

4

As it seems to me, the most close equivalent to JUnit assertion messages is withMessage() method introduced in FluentWait class. Below is the example of how I use it:

public class Test {
    public static void main(String[] args) {
        String[] paths = new String[]{  // Set proper and improper paths as an example of input
            "//img[@alt='Google']",     //Proper path
            "//img[@alt='Yahoo']"       //Improper path
        };
        WebDriver driver = new HtmlUnitDriver();                        // Instatiate web driver
        FluentWait<WebDriver> wait = new FluentWait<WebDriver>(driver)  // Set up settings for Fluent waits
                .pollingEvery(1, TimeUnit.SECONDS)
                .ignoring(NoSuchElementException.class);
        driver.get("http://google.com"); // Calling the test page
        for(String path: paths){         // Performing some test steps
            wait
                .withMessage("Element [" + path + "] not found and this is my user-friendly message")   // Setting up custom user-friendly message for each step
                .until(ExpectedConditions.presenceOfElementLocated(By.xpath(path)));                    // Invoking wait for the element
            System.out.println("Path [" + path + "] is OKAY");
        }
    }
}

And here is the part of the output with the user-friendly message:

Path [//img[@alt='Google']] is OKAY    
Exception in thread "main" org.openqa.selenium.TimeoutException: Timed out after 0 seconds: Element [//img[@alt='Yahoo']] not found and this is my user-friendly message
Build info: version: '2.52.0', revision: '4c2593cfc3689a7fcd7be52549167e5ccc93ad28', time: '2016-02-11 11:22:43'
    System info: host: 'TEST-HOST', ip: '1.2.3.4', os.name: 'Windows 7', os.arch: 'amd64', os.version: '6.1', java.version: '9.0.1'
    Driver info: driver.version: unknown
        at org.openqa.selenium.support.ui.FluentWait.timeoutException(FluentWait.java:292)
        at org.openqa.selenium.support.ui.FluentWait.until(FluentWait.java:261)
        at Test.main(Test.java:29)

So you can provide any message to be displayed in log for whatever supported conditions (or even your custom one).

  • 1
    I loved that answer, I'll pass it to my team so they can test/implement it, so I can provide further feedback – gvasquez Jan 30 '18 at 18:52
  • 2
    Very nice. Learned something new. – Bill Hileman Jan 30 '18 at 19:09
0

Generally speaking, automated tests are meant to be run un-interrupted. The optional messages that the JUnit assertions pass are passed for logging and/or reporting purposes and not really intended for interaction.

To the best of my knowledge there are no built-in display messages with pause via JUnit or TestNG for that matter. If you are encountering failures that are not expected during your test runs, I suggest using breakpoints and running in debug mode to determine the cause of your errors.

One thing that I have personally done to help me spot assertion errors more quickly in log files is to use System.err.println() when writing errors instead of the more standard System.out.println() as the error output device prints in red font and is much easier to spot when scanning down a very long log list. I'll do this either in addition to an assertion message or in lieu of an assertion message.

Hope this helps.

  • Thanks Bill for your answer but, I'm not intending to do any interactions. "Wait/until" are the class/method in the Selenium API, they wait for conditions in the testing browser while running the automated test – gvasquez Jan 30 '18 at 17:01
  • 1
    Okay, I think I read your question backwards. You want the wait methods to display a message, obviously if they fail. The solution, at least for me, is to wrap the findElement(s) methods. You do indeed need to use Try/Catch, but if you write one method it can handle quite a lot of scenarios and do the error trapping and reporting there, optionally raise exceptions, display/log specific error messages, etc. Am I on the right track now? – Bill Hileman Jan 30 '18 at 18:13
  • Way more "near" the right track...the try/catch solution does seems like a workaround and, the wrapper method is nicer but, I was wondering if there was something Selenium specific more elegant ;) – gvasquez Jan 30 '18 at 18:15

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.