public class ToDoMVCTest {

    @Test
    public void tasksLifeCycle() {

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

        add("1", "2");
        /*
            если добавляешь 2 таски сразу - то далее некак использовать неявные проверки
            ведь cancelRename("1" - проверит лишь состояние одной таски
            а у нас их 2
            значит - в данном случае - cancelRename("1" не будет неявной проверкой
            она - эта проверка - недостаточна

            не торопись добавлять таски раньше времени
            и будет все ок с неявными проверками
        */
        cancelRename("1", "1 edit canceled");
        toggle("1");
        assertTasksAre("1", "2");

        switchFilterToActive();
        assertTasksAre("", "2");
        assertVisibleTasksAre("2");
        /*
            достаточно проверки assertVisibleTasksAre
                даже если хочется точности - потом - возвратившись на all - проверишь не отфильтрованный по visible список тасок
                а на Active или Completed фильтрах - проверяй отфильтрованный по visible список
                раз на этих фильтрах - не все таски видимы
                далее везде - учти это

            switchFilterToActive - можно проще - filterActive
            что делать = filter-фильтровать, как фильтровать = Active
        */

        applyRename("2", "2 edited");
        /*
            toggleAll() - не является проверкой для операции applyRename("2"
            нужна проверка
        */
        toggleAll();
*****************************************************************
    private void add(String... taskText) {
/*
    мы оперируем не текстОМ таски, а текстАМИ тасок
    значит - параметр метода - назови taskTexts

    будет точнее
*/
*****************************************************
    private boolean assertItemsLeft(int count) {
        $("#todo-count").equals(count);
        return true;
    }
/*
    мы уже обсуждали это в прошлый раз
    еще перечитай про assertItemsLeft в прошлом ревью

    вариант $(...).equals(....); - вернет true или false
    и после этого - код продолжит выполняться ВНЕ зависимости от результата

    а далее - еще и true принудительно вернули)

    а вариант $(....).shouldHave(....) - будет работать вот так
    если проверка будет выполнена - то ок, тест будет выполняться далее
    если нет - тест упадет, что хорошо и правильно
    именно так и должны себя вести проверки в тестах
    если проверка не выполняется - тест должен упасть

    что делает метод equals - для объекта ЛЮБОГО класса
    метод сравнивает 2 объекта - объект, у которого метод вызван, и объект, который передан как параметр
    вряд ли нам это нужно)
    и есть ли смысл сравнивать объект класса SelenideElement ($("#todo-count")) и int count ?
    писала ранее - а также погугли java objects equals )
*/
***********************************************************

    private SelenideElement setNewTaskName(String oldTaskText, String newTaskText) {
    private void applyRename(String oldTaskText, String newTaskText) {
    private void cancelRename(String oldTaskText, String newTaskText) {
/*
    с реализацией  - ок

    с именами - советую изменить)
    мы уже оперируем понятием текст таски - taskText
    и уже вводим новый термин - TaskName

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

    предлагаю остаться с одним термином - taskText
    а методы - startEdit, edit, cancelEdit

*/
*******************************************
    private void switchFilterToCompleted() {
    private void switchFilterToActive() {
    private void switchFilterToAll() {
/*
    да, так тоже ок  - реализация

    про имена - уже писала
    можно лаконичнее
    filterCompleted
    filterActive
    filterAll
*/
*******************************
    private void assertTasksAreEmpty() {
    private void assertTasksAre(String... taskTexts) {
/*
    тут - все ок с реализацией
*/
    private void assertVisibleTasksAre(String... taskText) {
        for (String text : taskText) {
            tasks.filterBy(visible).shouldHave(exactTexts(taskText));
        }

    }
/*
    а вот тут - есть вопросы

    имя параметра метода
    мы работаем с текстАМИ тасок)
    taskTexts - будет ок

    читаем код
    в цикле, для каждого переданного текста тасок - мы делаем
    фильтруем таски по visible = получаем КОЛЛЕКЦИЮ видимых тасок
    и проверяем коллекцию - текстЫ тасок

    т е - по сути - делаем в цикле НЕСКОЛЬКО раз - одно и то же
    сколько тасок передали - столько раз это действие - верное действие и делаем

    уже вот этот код - tasks.filterBy(visible).shouldHave(exactTexts(taskText));- делает что нужно
    достаточно одного раза)

    а вот такой вызов - assertVisibleTasksAre();
    мы вообще в таком случае - ничего не проверяем - при текущей реализации

    теперь про видео Якова
    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 списком тасок)

    выводы
        или 2 проверки, или 4 проверки

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

*/