http://joxi.ru/DrlQ5oLh4WlKkm

/*
    мы реализуем проект на селениуме
    селениде  - уже не нужно подключать
    подправь pom
*/
****************************
    public static Actions action(){
        return new Actions(getDriver());
    }
/*
    Метод корректнее назвать actions()
    мы же создаем обїект типа Actions
*/
*********************************
 public static void setValue(WebElement element, String newTaskText) {
         element.sendKeys(newTaskText+ Keys.ENTER);
 }
/*
    setValue - это не только sendKeys
    это еще и предварительная очистка текста вебэлемента (clear())

    и в качестве параметра sendKeys - мы должны использовать ровно то, что нам передали
    а передали нам не newTaskText, а text or value - это универсальный метод
    и про тексты тасок тут рассуждать не стоит
    Keys.ENTER - не стоит добавлять
    нажатие энтера - не входит в логику установки нового значения

    если метод setValue вызовут setValue(element, newTaskText + Keys.ENTER)
    то будет как раз установить значение и нажать энтер

    а если вот так - setValue(element, newTaskText) - то только установим значение
    а нажатие энтера или чего-то другого - это будет уже слежующей задачей
    собственно, так и было ранее, когда мы в селениде это делали
*/
***************************************
    public static By byClassName(String nameText){
        return By.id(nameText);
    }
/*
    реализация не соответствует имени)
    да и не факт, что тебе нужен такой метод
*/
***********************************
    public static By byTitle(String titleText){
        return By.cssSelector(titleText);
    }
/*
    странный метод тоже)
    в прошлой работе такого же плана проблемы были
    это я пропустила)

    $("[title='Sent Mail']")
    $("[title~=Inbox]").click();

    вот так ты по тайтлу и ищешь

    выводы - или подправь неверные методы
    или удали их, раз не используешь

    в прошлой работе тоже

    http://pastebin.com/wtSFZgSH
    и про вот это тоже не забудь
*/
**********************************
 List<String> actualTexts = new ArrayList<String>();
 for(WebElement element:listElements){
    actualTexts.add(element.getText());
 }
/*
    этот код используется в кондишенах не раз
    реализуй универсальный метод
    List<String> getTexts(List<WebElement> elements)
    и его переиспользуй в кондишенах

    расположи такой метод в классе-контейнере универсальных статических методов Helpers
*/
**********************************
 public String toString() {
    return String.format("\nTexts of list elements should be : %s\n while actual texts is: %s\n", actualTexts.toString(), Arrays.toString(expectedTexts));
 }
/*
    все сообщения пересмотри в кондишенах
    важно рассказать
    что мы проверяем
    для какого элемента/элементов мы проверяем
    что ожидаем
    что есть по факту

    тут было бы ок
    texts of list elements found by locator ...
    should be :
    while actual texts is:

    обрати внимание - should be : - это проожидания (а не про факт)
    посмотри - как строку строишь

    и про вывод локатора не забывай

    ну и не надо писать про тексты - если ищем не тексты, а что-то другое

    toString() всех реализованных кондишенов просмотри
*/
***********************************
visibleTextsOf
/*
    сначала - получи список видимых элементов
    потом - с помощью метода getTexts получи тексты видимых элементов

    получение списка видимых элементов - тоже используется несколько раз
    это тоже стоит реализовать как метод в классе Helpers
*/
************************************
sizeOfVisible
/*
    тут нам не нужно оперировать текстами элементов
    достаточно получить список видимых вебэлементов
    и его размер
    Поскольку в toString - будешь оперировать фактическим размером списка
    то на уровне класса-кондишена - объяви переменную actualSize
    запоняй ее в apply
    и выводи это значение в toString

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

    кстати, полезнее, чтобы эти кондишены были
    не ExpectedCondition<Boolean>
    а ExpectedCondition<List<WebElement>>

    чтобы в случае успешной проверки
    assertThat вернул не просто true
    а список вебэлементов
*/
********************************
public static ExpectedCondition<WebElement> listElementWithText(final By locator, final String expectedTexts) {
/*
    мы же ищем элемент с текстОМ, а не текстАМИ
    подправь имя параметра expectedTexts

    тут, как и в texts
    собери тексты элементов
    и ими оперируй
    и в apply
    и в toString()

    List<WebElement> listElements; - объявляй и инициализируй в apply
    т к только там и нужен этот список

    в toString() - нам ничего не даст его использование
    listElements.toString() - мало информативно
    в отличие от actualTexts.toString()

    не забывай про выражения toString()
    выше описала - по какой схеме формулируй их
    не надо писать о том, что ошибка - Element not found,...
    опиши - что проверяешь, у какой сущности проверяешь, что ждешь и что получил по факту
    так мы просто опишем наш кондишен
    ведь toString() - это способ преобразования объекта к строке
    а не текст ошибки
    да, по факту, практически всегда toString() кондишена и вызывается в сообщении об ошибке при
    не выполнении проверки new WebDriverWait(...).until(...)
    но все равно надо быть корректным
    toString() - это метод, описывающий объект, приводящий объект к строке
    и технически - некорректно строить фразы про то, что у нас ошибка и т п
    корректно - описать наш кондишен

*/
*******************************
  public static ExpectedCondition<WebElement> listElementByCssClas(final By locator, final String expectedCssClass) {
  /*
    в имени кондишена букву потерял
    не Clas
    а  Class

  */

        return elementExceptionsCatcher(new ExpectedCondition<WebElement>() {
            List<WebElement> listElements;
            /*
                этот список нужен только в apply
                вот там его и объявляй
            */
            List<String> listCssClass = new ArrayList<>();
            /*
                не корректное название списка
                по сути - это значения атрибута class
                а не  css классы

                    Имя элемента и его классы
                    в выражении
                    <element class=“green bold”>
                    element - имя элемента
                    class -  имя атрибута
                    “green bold” - значение атрибута class
                    green - цсс класс элемента element
                    bold - еще один цсс класс элемента element

                classAttributes, classList - корректнее
                (главное слово - последнее)
                https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#bookmark=id.ubyujhyxdfwd
            */
            public WebElement apply(WebDriver driver) {
               ...

                    if (listCssClass.get(i).contains(expectedCssClass)) {
                    /*
                        не верно проверять на вхождение
                        например у элемента классы = "active editing"
                        мы проверяем этот кондишен для класса "edit"

                        при вот так реализованном кондишене - проверка пройдет
                        хотя не должна была

                        нам надо значение атрибута class
                        разбить на слова (по пробелам)
                        и если в этом перечне слов будет слово, в точности равное искомому классу
                        то вот тогда - ок, проверка прошла
                    */
***********************************************
public class ToDoMvcPage {

    public WebDriver driver;
    public ToDoMvcPage(){
        driver = getDriver();
    }
/*
    даже если организуешь пейдж-объект
    уже не нужно делать ему поле-вебдрайвер

    ведь ты и из пейджа можешь вызвать getDriver()

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

    но вот конструктор и поле driver - в любом случае лишние
*/
*************************************
public static void   edit(String oldTaskText, String newTaskText) {
public static void   cancelEdit(String oldTaskText, String newTaskText) {
/*
    за счет изменений в реализации setValue - код станет на одну строчку короче

    да и давай эти методы DRY реализуем

    как и для селедиде проекта
    реализуй метод WebElement startEdit(String oldTaskText, String newTaskText)
    в котором будут все общие для этих методов действия
    и возвращать будешь элемент - в котором вводил новое значение

    а если еще и setValue будет возвращать WebElement
    так и в startEdit сможешь код поаккуратнее написать)
*/
***********************
public class GMailTest extends BaseTest {
    @BeforeClass
    public static void config() {
        Configuration.timeout = 15;
    }
/*
    начало слегка озадачило)

    почему GMailTest? )

    да и таймаута стандартного в 4 секунды нам должно хватить с головой)
*/
    public static  void visit(){ open("https://todomvc4tasj.herokuapp.com/");}
/*
    такому методу - место в пейдже
    или - если такой метод оставлять в тест-классе
    его нужно аннотировать как @BeforeClass
    и уже в тест-методах не вызывать
*/
****************************************
public class BaseTest {

    @Before
    public  void createDriver() {
        setDriver(new FirefoxDriver());
    }


    @After
    public  void quit() {
        getDriver().quit();
    }


}
/*
    если для каждого тест-метода использовать свой вебдрайвер
    тогда конечно - и чистить локалсторидж не нужно)

    все верно)

    но если ты запускаешь тесты в одном потоке - это роскошь - для каждого тест-метода создавать свой вебдрайвер
    гораздо экономичнее в таком случае использовать
    не @Before и @After методы
    а @BeforeClass и @AfterClass методы

    ну и про очистку локалсториджа надо будет подумать (уже в тест-классе)

    про параллельный запуск - следующая работа
    там как раз понадобится вариант с @Before и @After методами
*/