public class GmailTest extends BaseTest {

    @BeforeClass
    public static void configure() {
        Configuration.timeout = 20;
    }
/*
    заметила - что раньше вот так было...
    если запускать все тесты проекта
    то вот эта строчка очень портит картинку)
    что объяснимо - таймаут у нас в миллисекундах

    может - собственно поэтому у тебя в прошлый раз тесты и не запускались нормально?

    погоняла все тесты - все бегает)
    это ок
    правда, пришлось чуть подправить google search - но то уже особенности відаси результатов поиска
    возможно - у тебя ок с твоим кодом
*/
*********************************
    public static void followLink(int index) {
        results.shouldHave(minimumSizeOf(index + 1));
        results.get(index).find(".r>a").click();
    }

/*
    не надо тут results.shouldHave(minimumSizeOf(index + 1));

    как click() работает в нашем лейзи-элементе - дожидается его видимости
    так что - все ок будет и без предварительной проверки
*/
********************************************
new WebDriverWait(getDriver(), 4).until(urlContains("http://www.seleniumhq.org/"));
/*
    можно кстати вернуть в ConciseAPI assertThat - который работал с родными селениумскими кондишенами
    вот тут - пригодился бы )
*/
********************************************
public static Condition<List<WebElement>> listIsEmpty()
/*
    можно полаконичнее назвать кондишен empty()
    касается и метода, и класса

    аналогично - для sizeOf и minimumSizeOf
    это раньше - когда первым параметром был локатор - этот Of был уместен
    теперь - точно лишнее
    size и minimumSize - будет полностью ок
*/
***********************************
public static void visit() {
        open("https://todomvc4tasj.herokuapp.com");
}

/*
    думаю - лишний метод)
*/
************************************
static LazyCollection mails = $("[role = 'main']").findAll(".zA");
/*
    мы и вот так можем переменные объявлять)

    т к в конструкторах наших лейзи-сущностей - мы ничего не ищем...
    только запоминаем  - как нам такую сущность искать

    верни назад - старый вариант
    static LazyCollection mails = $$("[role = 'main'] .zA");

    проверили findAll  - и хорошо
*/
**************************************
public static void assertMail(int index, String text) {
        mails.get(index).shouldHave(ElementConditions.text(text));
}

public static void assertMails(String... texts) {
        mails.shouldHave(texts(texts));
}
/*
   shouldHave - предполагает работу с кондишеном и только с кондишеном
   потому смело используй import static

   конечно, получится не очень понятно - .shouldHave(text(text));
   но - в случае shouldHave(texts(texts)) - тебя это не смутило)

   самое красивое решение - переименовать параметры методов в mailText & mailTexts
   и использовать import static

   получишь
   shouldHave(text(mailText))
   shouldHave(texts(mailTexts))
*/

/*
    как ты понимаешь - весь код полируем)
    скоро финиш)

    так что - и сами тест-методы и пейджи - все просмотри
    поправь выравнивание
    реформатируй

    ну и то что я написала - тоже поправь
*/
*************************************************
    @Override
    public boolean is(Condition<WebElement> condition) {
        return condition.check(lazyElement.getWrappedEntity());
    }
/*
    Тут надо ловить WebDriverException

    чтобы гарантированно is не падал
    а просто возвращал - да/нет

    если падает - значит возвращай - нет
*/
************************************************
public WebElement fetchWrappedEntity() {
        List<WebElement> parentCollectionWrappedElements = parentCollection.getWrappedEntity();
/*
    ага, молодец, все ок реализовала

    твой вариант, конечно красивее был
    но этот пошустрее

    переменную parentCollectionWrappedElements
    можно и попроще назвать
    parentElements, elements - будет ок )
*/
******************************************
public class LazyElementInnerCollection extends AbstractLazyCollection {

    @Override
    public String toString() {
        return parentElement.toString() + " find(" + innerLocator + ")";
    }

/*
    и реализовала, и оттестила - молодец)

    в toString() все же уточни - не " find(", а " findAll("
*/
***********************************
public class ExactTexts extends CollectionCondition {
    protected String[] expectedTexts;
    protected List<String> elementTexts;

/*
    насчет использования модификатора доступа protected

        есть такая точка зрения, что использовать protected - это самообман
        т к в рамках потомков можно для отнаследованного protected-метода
        этот метод сделать публичным

        когда мы использовали protected, мы хотели, чтобы что-то было с возможностью наследования
        и не хотели его внешнего использования.
        а кто-то отнаследовался от нашего класса и объявил это как public
        и вот то, что мы прятали внутри класса - уже "торчит" наружу

        есть good practice - избегать применения protected
        то, что мы что-то объявим внутри класса-кондишена как public
        не будет нам особо мешать при работе с нашим фреймворком
        т к в итоге - используем для кондишена тип интерфейс,
        и это позволит не светить нашими публичными переменными/методами
        когда будем юзать фреймворк

        идеально про протектед-методы
            http://programmers.stackexchange.com/questions/162643/why-is-clean-code-suggesting-avoiding-protected-variables
            http://joxi.ru/52akqzoUGnqYGr

            http://stackoverflow.com/questions/3631176/why-are-many-developers-opposed-to-using-the-protected-modifier-in-oop
            http://stackoverflow.com/questions/37011/should-you-ever-use-protected-member-variables
            http://stackoverflow.com/questions/4913025/reasons-to-use-private-instead-of-protected-for-fields-and-methods

            http://www.javalobby.org/java/forums/t77911.html

    Просмотри весь проект, перейди на использование public
*/
******************************************

public class ExactTexts extends CollectionCondition {
 ...

    @Override
    public boolean check(List<WebElement> elements) {
    ...
               if (!elementTexts.get(i).equals(expectedTexts[i])) {
               /*
                    фактически - только эта строка и отличает реализацию метода
                    check в этом кондишене и его потомке

                    можно
                    в этом классе реализовать метод checkElement(int index)
                    ровно с такой проверкой

                    и тогда в потомке - check убери полностью
                    и просто перереализуй checkElement(int index)
                    кода станет еще меньше )
               */
    ...
********************************************
public static Condition<WebElement> visible() {
        return new Visible();
}
/*
    по идее - можно было еще короче)
*/
public static Condition<WebElement> visible = new Visible();

/*
    т е - реализовывать не метод, а статическую переменную
    вроде бы - лаконичнее, что хорошо

    но - не так уж и хорошо)

    Тут есть такая тонкость)

    мы создали статические переменные = объект-кондишен

    и используем их в проекте, который поддерживает параллелизацию

    если мы в параллельных тестах будем использовать ОДИН объект-кондишен ОДНОВРЕМЕННО
    могут возникать странные ошибки

    чтобы избежать этого
    вместо переменных стоит использовать методы
    тогда для каждого вызова кондишена мы будем использовать свой объект
    и таких проблем не будет

    наш текущий вариант с методом - грамотнее)
*/