public class BaseTest {
    public static WebDriver driver = new FirefoxDriver();

    @AfterClass
    public static void closeBrowser() {
        driver.quit();
    }
}
/*
    перенес предка тест-класса в верную ветку проекта
    а в целом - структурно - ок

    вот этот момент не очень удачный
    http://joxi.ru/l2ZNaR0FwwDGv2
    2 - снова пекедж test
    хотя мы уже и так в ветке src \ test

    советую убрать из структуры пекедж test (2)

    и ты таки не прислушался к совету http://pastebin.com/rX3xAQf1, строки 14-20
    создавай драйвер в BeforeClass-методе
    если этот совет не понятен, или ты не видишь - как это проявляется - давай пообщаемся на эту тему
    тонкий момент)
*/
**************************
public static ExpectedCondition<List<WebElement>> textsOf(final List<WebElement> elements, final String... texts) {
/*
    кетчер применил удачно

    но - напрасно из реализации кондишена - убрал сборку списка фактических текстов и последующую работу с ними
    и в кондишене - не хватает toString-метода

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

    еще в чем плюс работы со списком фактических текстов
    прокси-список веб-элементов - elements - постоянно переискивается при работе с ним
    потому - ты можешь столкнуться с тем, что после сравнения if (elements.size() != texts.length)
    размер списка вебэлементов - снова поменяется, и при анализе текстов - возникнут какие-то новые сложности


    все же в кондишенах (даже с параметром-локатором, и с прокси-списком или элементом - это вообще критично)
    стоит придерживаться такой схемы
    сначала - собираем фактические данные (те, которые проверять будем)
    и запоминаем их в соответствующем поле класса
    затем - уже сравниваем эти фактические данные с ожидаемыми
    и в toString - возвращаем фразу, в которой описаны и ожидаемый результат, и фактический
    (заметь - мы собрали фактический результат - единожды
    и на каких данных делали выводы - те и описали в toString - это мы с тобой и по скайпу обсуждали,
    и было это в предыдущих ревью)

    в toString - не нужно заново получать фактические результаты
    в случае с параметром кондшена - прокси-списком или элементом - ты банально можешь другое получить
    в случае с параметром кондшена - локатором - это также критично, если заново получать по локатору элемент или список,
    а если пользоваться ранее полученным - то это лишняя работа
    в общем - выше описанная схема - хороша, и кажущаяся на первый взгляд избыточность - нужна
*/
***************************
public static ExpectedCondition<WebElement> listNthElementHasText(final List<WebElement> elements, final int index, final String text) {
        if (text.length() == 0) {
            throw new IllegalArgumentException("Array of expected texts is empty.");
        }
/*
    посмотри внимательно, что есть text и что есть text.length()
    корректно ли сообщение

    и не хватает в реализации кондишена - метода toString
*/
*******************************
public static ExpectedCondition<Boolean> textsOfNew(final List<WebElement> elements, final String... expectedTexts) {
/*
    избавляйся от лишнего
    ведь уже есть ExpectedCondition<List<WebElement>> textsOf(final List<WebElement> elements, final String... texts)
*/
****************************
/*
    А в целом - с кондишенами уже все неплохо
    разобрался - что и когда возвращать
    это ок

    И с применением кетчера - тоже ок

    но - доработать нужно - что выше описано - сбор фактических результатов и их анализ, плюс - toString
    иначе - могут быть нестабильно проявляющиеся проблемки
    и гарантированно - неинформативное сообщение при падении проверок кондишена
    согласись, серьезные недостатки
*/
************************
/*
    Интересное решение - по пекеджам pages
    в src \ main\ ...\ pages - предок
    в src \ test\ ... \ pages - уже пейджи

    Имеет право на существование

    вообще - можно рассуждать так
    если в проекте - содержатся только тесты (бывает, что тестируемое прилоение и его тесты - в одном проекте находятся)
    так вот если в проекты - только тесты
    то пейджи можно вынести в в src \ main\ ...\ pages - как переиспользуемые инструменты
    в таком случае я бы разместила предка пейджа - в в src \ main\ ...\ core

    но и твоя версия структуры - вполне ок
*/
***************************
/*
    Остальное - ок

    стратегия следующая

    доработай кондишены в этой версии
    и далее - либо в этом же репозитории, но в другом branch-е
    либо - в другом репозитории - реализуй следующий проект

    уже в следующей версии - помимо описанного в условиях
    переходи на работу без @FindBy элементов и списков
*/