ElementsCollection tasks = $$("#todo-list > li");

/*
    технически - верный селектор

    лучше в таких случаях убрать пробелы вокруг ">"
    да, ты ничего не нарушаешь)
    но проще и однозначнее - вот такой селектор "#todo-list>li"

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

    http://www.w3schools.com/cssref/css_selectors.asp
*/
***************************
    @Test
    public void testTasksLifeCycle() {

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

        add("a");
        startEdit("a", "a-edited").pressEnter();
        assertItemsLeft(1);
        //complete
        toggle("a-edited");
        /*
            тут проверь состояние списка тасок - assertTasks
            так проверим - что на all фильтре таски отображаются вне зависимости от статуса
            и проверка - после перехода на Active фильтр
                допроверяет - что таки таска была закомпличена
                и точно проверяет переход на фильтр
        */

 ******************************************

    private void assertTasks(String... taskTexts) {
        tasks.shouldHave(exactTexts(taskTexts));
    }

    private void assertVisibleTasks(String... taskTexts) {
        tasks.filter(visible).shouldHave(exactTexts(taskTexts));
    }

    private void assertNoTasks() {
        tasks.filter(visible).shouldBe(empty);
    }
/*
    немного прокомментирую видео
    https://drive.google.com/file/d/0B8hgIBw8-V-AdGxxU1R3enl1RzQ/view?ts=567ab8d7

    мы можем быть максимально точными и держать 4 проверки
    2 -
        в списке = такси с такими-то текстами
        в списке = пусто
    и еще 2 -
        в отфильтрованном по visible списке = таски с такими-то текстами
        в отфильтрованном по visible списке = пусто

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

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

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

    Но - возможно - если мы уже отдельно это в тестах покрыли -
    что у нас не копятся невидимые таски - так мы и не платим ) И - тогда - все проще в написании тестов,
    и в их сопровождении.

    Тогда - поскольку обе проверки реализованы одинаково и других нету - можно из имен проверок скрыть этот нюанс
    и назвать их assertTasks и assertNoTasks (хотя в них работаем с отфильтрованным по visible списком тасок)

    Варианты промежуточные - когда у нас 3 проверки
    причем когда мы в именах проверок не придерживаемся одной логики
    (то рассказываем про фильтрацию по visible, то не рассказываем)
    этот варианты не однозначны, вызывают вопросы )

    Определись с вариантом)
*/