Есть подозрение, что я намудрила с toString(), может сделала не совсем так, как ты писала. У меня сейчас вот так выглядит ошибка:

***********
org.openqa.selenium.TimeoutException: Timed out after 4 seconds waiting for SizeOf
for WebElements from By.cssSelector: .srg>.g
expected: 10
actual: 0
…….

**************
org.openqa.selenium.TimeoutException: Timed out after 4 seconds waiting for Text
for WebElement from parentCollection[0] = [[FirefoxDriver: firefox on WINDOWS (3421be5a-bbfc-4701-912f-fe420d771fea)] -> css selector: .srg>.g]
expected: Selenium automates browsers111
actual: Selenium - Web Browser Automation
www.seleniumhq.org/
……..

/*
    давай разбираться )

    начало фразы - формируется в WaitFor#until
*/
public class WaitFor {
  ...
    public <V> V until(Condition<V> condition, long timeoutMs) {
       ...

        throw new TimeoutException(String.format("Timed out after %s seconds waiting for %s", Long.toString(timeoutMs/1000), condition.toString()), lastError);
    }

/*
    в принципе - вот этот первый кусочек - Timed out after 4 seconds waiting for  - вопросов и не вызывает ....

    можно чуть переформулировать  - failed while waiting ... seconds to assert ...

    дальше - надо смотреть на реализацию condition.toString()

    смотрим ...
    сначала - на общего абстрактного предка всех кондишенов
*/
public abstract class AbstractCondition<T> implements Condition<T>, DescribesResult{

 ...
    public String toString() {
            return String.format(getClass().getSimpleName() +
                    "\nfor " + identity() + " from " + entity +
                    (expected() == "" ? "" : "\nexpected: " + expected()) +
                    (actual() == "" ? "" : "\nactual: " + actual()));
    }

}
/*
    вместо " from " + entity +
    можно " found by: " + entity
    будет чуть лучше

    идем по иерархии дальше - смотрим на следующих потомков

    кстати, а когда expected() или actual() возвращают "" ? ""?
    надо ли такой вариант предусматривать вообще?
*/

public abstract class AbstractElementCondition
/*
    фактически - мы тут только тип уточнили - что это потомки AbstractCondition<WebElement>
    ну и уже по мелочи - реализовали тут  identity()
*/
    ...

    @Override
    public String identity() {
        return "WebElement";
    }
    /*
        корректнее - element
    */

/*
    смотрим на второго потомка ...
*/
public abstract class AbstractCollectionCondition ...
...

    @Override
    public String identity() {
        return "WebElements";
    }
    /*
        тут  - верни collection или  elements

        collection - даже лучше - быстрее разницу увидеть можно
        element vs elements
        element va collection - в этом варианте нагляднее
    */
/*
    дальше - смотреть надо на реализации expected() & actual() в кондишенах
    (тут меня ничего не смутило - все корректно)

    и на toString лейзи-сущностей
*/

/*
    думаю - после этих изменений вопрос решится

    во всех лейзи-объектах - должен быть реализован метод toString()
    также как и кондишенах - expected() & actual()
*/
*********************************************
Когда я в интерфейсе объявляю метод , например find(),
а потом его имплементирую в классе, который имплементирует этот интерфейс надо указывать аннотацию
@Override или нет? Пробовала проверить с помощью идеи, используя Alt+Insert,
но идея сама добавляет эту аннотацию.
А мне кажется, что она не нужна, ведь это не другая какая-то отличная реализация этого метода,
а его первая реализация. Больше ни в каком классе ее нет.

/*
    технически - ты вообще можешь эту аннотацию не использовать

    но - согласно конвеншенсов она нужна
    https://google.github.io/styleguide/javaguide.html#s6.1-override-annotation

    http://stackoverflow.com/questions/212614/should-we-override-an-interfaces-method-implementation
    http://stackoverflow.com/questions/94361/when-do-you-use-javas-override-annotation-and-why

    по второй линке тоже похожие вопросы рассматриваются)
    и народ про них спорит - есть и pro, и contra )

    но вот у гугла в конвеншенсах - указано использовать
*/
****************************
public class LazyElementInsideElement extends AbstractLazyElement {
/*
    назови класс LazyElementInnerElement

    схема = Lazy + откуда + уточнение + Element

    в toString - выведи что-то типа parentElement.toString() + " find(" + innerLocator + ")";

    остальная реализация - ок
*/