public static ExpectedCondition<Boolean> ajaxCompleted = new ExpectedCondition<Boolean>() {
/*
    т е - реализовывать не метод, а статическую переменную
    вроде бы - лаконичнее, что хорошо

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

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

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

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

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

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

    вариант с методом - грамотнее)
*/
******************
    for (String taskName : taskNames)
            add(taskName);

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

    https://google.github.io/styleguide/javaguide.html#s4.1.1-braces-always-used

    все логично - потом начнем дописывать код
    про скобки не подумаем
    вот и ошибка

    в долгосрочном периоде - это такая защита от глупых случайных ошибок
*/
*****************************************
private By tasks = By.cssSelector("#todo-list li");
//можно проще
private ElementsCollection tasks = $$("#todo-list li");
//а еще лучше - вот так
private ElementsCollection tasks = $$("#todo-list>li");
/*
    Вся перелесть селенидовских коллекций и элементов в том - что когда ты их объявляешь и инициализируешь
    еще ничего не происходит
    это можно делать заранее
    фактически - мы просто описываем - как нам найти элемент или коллекцию

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

    что касается селектора "#todo-list>li"
    то он - точнее
    для нашего примитивного прилодения - и твой вариант ок
    но иногда эта разница бывает существенной
    http://www.w3schools.com/cssref/css_selectors.asp

    если tasks объявили как
        ElementsCollection tasks = $$(...);
    то используем его
        не  $$(tasks).findBy(...
        а      tasks.findBy(....
    Ведь tasks - уже коллекция

*/
************************
public TaskPage destroy(String... taskNames) {
/*
    так - нам точно не нужно

    почему мы реализовали  add(String... taskNames)
    потому что - иногда на начало теста - нам сразу нужно добавит несколько тасок

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

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

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

    что до реализации метода
    его конечно реализовывать - не нужно было
    но уже если делать - то чтоб он был надежнее и проще - лучше сделать вот так
    for (String taskName : taskNames) {
        destroy(taskName);
    }
    и все)

    вариант обхода - for (SelenideElement e : $$(tasks))
    плох тем, что на момент старта обхода - на странице  могут  еще недогрузиться элементы в списке
    получается - ненадежно и код раздутый

    а в мной предложенном варианте - каждый раз делая  destroy(taskName)
    мы, фактически, дожидаемся - что таска с таким именем в списке есть
    и начинаем с ней работать

*/
*******************************
public TaskPage completedShouldHaveTexts(String... texts) {
public TaskPage completedListShouldBeEmpty() {
/*
    Методы реализованы пристойно

    но - они все равно не нужны)
    про это Яков говорил в видео
    https://drive.google.com/file/d/0B8hgIBw8-V-AUDhxWDg1YmYxM3c/view?usp=sharing
    примерно с 58-ой минуты, минут 5-7 посмотри

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

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

    пример

    мы на All фильтре
    закомплитили таску
    проверили тексты всех тасок = проверили часть логики = на all фильтре все таски отображаются в списке вне зависимости от статуса

    перешли на Active
    проверили тексты всех видимых тасок =
        точно провелили фильтеринг
            фильтеринг работает, т к состояние списка тасок изменилось
            фильтеринг работает правильно, т к новое состояние списка тасок верное
        и допроверили закомпличивание = таска закомпличена
            причем - мы это првоеряли именно с точни зрения функциональности
            а не проверок UI (User Interface)

     тут, в этом задании, мы можем себе позволить
        вариант 1 - пропустить проверки после закомпличивания
        вариант 2 - проверить тексты всех тасок (= проверить = на all фильтре все таски отображаются в списке вне зависимости от статуса)
*/
*********************************
public TaskPage shouldHaveTexts(String... texts) {
public TaskPage listShouldBeEmpty() {
/*
    при нейминге - старайся придерживаться одной логики для похожих случаев

    shouldHaveTexts - мы не уточняли, что работаем со списком тасок (подразумевали это)
    listShouldBeEmpty() - а тут уже уточнили, причем ДО слова should

    т е - теперь - мы то начинаем названия методов-проверок со слова should, то нет
    и то уточняемся до list, то нет

    варианты
        shouldHaveTexts(String... texts)
        shouldBeEmpty()
        с учетом имени пейджа - проде как достаточно

        или вот так
        assertTasks(String... taskNames)
        assertNoTasks()
        тут мы уже ничего не скрываем
        и строим фразы - по одним и тем же правилам
        https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#bookmark=id.sswzyp7qkm9o

*/
**************************
String... texts
//или
String... taskNames
/*
    Определись с термином

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

    никаких разных терминов/синонимов/сокращений

    тогда код будет проще понимать, он будет однозначнее

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

    если выберешь taskNames, к примеру
    то для одной таски - получишь - соответственно - taskName
*/
***************************************
public class TodoMVCTest extends BaseTest {
/*
    не понимаю ценности BaseTest
    поясни, что из реализованного в BaseTest - ценно
*/
*****************************
  page.destroy("2", "3")
/*
    не фантазируй)
    это будешь в следующей задаче делать)
    тут - нужно удалить лишь таску 2

    да и если бы требовалось удалить 2 таски - были бы нужны проверки - после каждого шага

    общее правило такое - каждый шаг должен быть проверен

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

    а вот с destroy("2", "3") - другая история уже
    тут пропуск проверки повлияет на точность проверок

    почему точность проверок - это так важно
    если мы сэкономили на проверках - вроде как хорошо - тест быстрее бегает
    но - во-первых - мы можем банально пропустить ошибку
    во-вторых - по возникшей ошибке - не сможем БЫСТРО сказать - что не работает - то-то
    будем какое-то время - разбираться
    так что - экономия на проверках - плохая экономия)
*/
*************************
page.clearCompleted();
page.completedListShouldBeEmpty();
/*
    после clearCompleted() - точно стоит проверить тексты всех тасок, а не только закомпличеных
    про проверки после закомпличивания - писала выше
*/