@Test
    public void testTasksLifeCycle() {

        open("https://todomvc4tasj.herokuapp.com/");

        add("task1");
        edit("task1", "task1 edited");
        assertTasksAre("task1 edited");
        toggle("task1 edited");
        /*
            после edit - не нужна проверка
            т к toggle("task1 edited"); - проверит состояние единственной таски

            а вот после toggle("task1 edited");
            нужно проверить состояние списка тасок
            проверки assertTasksAre("task1 edited"); - будет достаточно
            это проверит часть логики - что таски не зависимо от статуса - будут отображаться в списке
            а фильтре all

            а после перехода на Active - проверка списка тасок
            допроверит закомпличивание и точно проверит переход на Active
        */

        filterActive();
        /*
            следующая операция - не проверяет переход на Active
            нужна проверка
        */
        toggleAll();
        /*
            это - действие reopen all
            мы уже обсуждали
            что у reopen all - приоритет не высокий
            и reopen all - в рамках smoke - мы не будем вообще

            после перехода на Active() -
            в списке не будет ни одной видимой таски
            вот добавь таску и с ней работай
        */
        cancelEdit("task1 edited", "task1 edited canceled");
        /*
            следующая операция не проверяет предыдущую
            значит что нужно сделать?
        */
        add("task2");
        assertTasksAreVisible("task1 edited", "task2");
        toggle("task1 edited");
        /*
            complete - уже покрыто  - на All
            если там покрыл complete
            то тут покрой - complete all

            этот разговор уже тоже был)
        */
        assertItemsLeft("1");
        /*
            этой проверки недостаточно
            нужна проверка списка тасок
        */

        filterCompleted();
        /*
            нет проверки
        */
        clearCompleted();
        /*
            нет проверки
        */
        toggleAll();
        /*
            покрывать в рамках smoke - complete all on completed filter
            не верно

            вспомни свою же работу http://pastebin.com/yaXRt94S
            вопрос - почему мы не включили  complete all on completed filter - в основные юз кейсы?

            все дело в приоритетах этого действия на этом фильтре
            ведь complete all on completed filter - будет гораздо реже востребован, чем на других фильтрах
        */
        assertTasksAreVisible("task2");

        filterAll();
        delete("task2");
        /*
            проверка перехода на all фильтр - получилась не удачной
            т к состояние списка - не изменилось
            тоже смотри прошлые ревью
            было про то - как поточнее проверять переход на другой фильтр
        */
        assertNoTasks();
    }
**********************************************
/*
    надеялась уже этого не делать,
    рассчитывала - что сам такую работу проведешь над своим кодом
    анализируем покрытие
*/
    All
        add
        edit
        complete
        delete

    Active
        reopen all
        cancelEdit
        add
        complete

    Completed
        clearCompleted();
        complete all
 /*
        complete - покрыт дважды, что лишнее
        complete all - покрыт на Completed фильтре, там у этого действия невысокий приоритет
        (разумнее вместо второго complete - выполнить это на Active, например)
        reopen all - у этого действия невысокий приоритет, вообще не стоит его покрывать
        reopen - не покрыто, разумнее всего это сделать на Completed фильтре - будут наиболее точные проверки
 */
***********************************
/*
    про порядок методов - не прислушиваешься
    объясни мне это в слеке - почему?
*/
*****************************************
    private void assertTasksAre(String... taskTexts) {
    private void assertTasksAreVisible(String... taskTexts) {
    private void assertNoTasks() {
/*
    измени имя метода assertTasksAreVisible на assertVisibleTasksAre
    ведь в нем мы не проверяем - что таски видимые, а проверяем - что видимые таски = такие-то

    смотри видео
    https://drive.google.com/file/d/0B8hgIBw8-V-AdGxxU1R3enl1RzQ/view?usp=sharing

    сразу к нему пояснения
    мы можем быть максимально точными и держать 4 проверки
        2 -
            в списке = такси с такими-то текстами
            в списке = пусто
        и еще 2 -
            в отфильтрованном по visible списке = таски с такими-то текстами
            в отфильтрованном по visible списке = пусто
        И за точность будем платить  тем - что надо думать - когда какую проверку вызвать правильнее
        и если это делать бездумно - то при небольших изменениях сценариев - могут тесты падать на проверках,
        или второй вариант - не будем нормально пользоваться полученной точностью...

        мы можем исходить из того, что ошибку, когда невидимые таски копятся в списке - мы тестим на более низком уровне,
        и на UI уровне - нам не нужно до этого уточняться. Поэтому - мы будем держать всего 2 проверки
              в отфильтрованном по visible списке = таски с такими-то текстами
              в отфильтрованном по visible списке = пусто
        В таком случае - каждый раз понятно - какую проверку вызывать - получаем более KISS картину
        правда, платим за это точностью) Но - возможно - если мы уже отдельно это в тестах покрыли -
        что у нас не копятся невидимые таски - так мы и не платим ) И - тогда - все проще в написании тестов,
        и в их сопровождении.
        Тогда - поскольку обе проверки реализованы одинаково и других нету - можно из имен проверок скрыть этот нюанс
        и назвать их assertTasks и assertNoTasks (хотя в них работаем с отфильтрованным по visible списком тасок)

    вариант с 3 проверками - хуже
        чем 2 проверки, или 4 проверки

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

            ...
            я сделал 3 метода - 2 для проверки наличия и отсутствия видимых задач
            и один для проверки, что задач вообще нету - чтоб в самом конце использовать
            и подумал - что таким способом убиваю двух зайцев
            только на один метод увеличиваю количестко методов
            и контролирую в конце - чтоб невидимых задач не оставалось

            Согласна, вроде бы резоны твои  разумные
            И точность гарантируем, и лишнего не реализуем
            Но тогда в именах методов - надо четко указывать - где работаем с visible тасками, а где без такого отбора
            Ну и недостаток тоже у такой схемы есть
            Это хорошо - код оптимизирован
            Но - людям, что не в теме - вариант с тремя методами покажется менее понятным скорей всего
            (по сравнению с 2 и 4 )
            И второе - а где гарантия - что сценарий какой-то другой закончится именно пустым списком тасок
            Следовательно - для общего случая - если мы намерены быть точными - таки надо держать 4 метода
            А вообще - что список тасок не нарастает - разумнее проверять на более низком уровне тестирования
            А тут - оставить 2 проверки (с фильтрацией по видимости)
            Такими инструментами будет гораздо проще пользоваться
            Ну ты это чуть дальше - оценишь)
*/

    private void assertItemsLeft(String itemsLeft){$("#todo-count>strong").shouldHave(exactText(itemsLeft));}
/*
    не забывай про реформатирование кода
    выдели код + в меню IntelIJ Idea - code->reformat code

    имя параметра itemsLeft - просто повторяет кусок имени метода
    ничем не дополняет и не поясняет
    полезнее было бы имя count, activeTasksCount - что-то такое
    также - измени тип параметра
    это - не строка по сути
    а именно - число активных тасок
    потому - параметр объяви как число

    реализация проверки верная
    просто будешь число преобразовывать в строку и передавать как параметр в exactText
*/