public class ToDoMVCSmokeTest {
/*
    Smoke - это важная информация о покрытии
    но не о тест-классе или тест-методе)

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

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

    тут  - будет ок = ToDoMVCTest
    а вот  - пекеджи - делай согласно заданиям
    типа
    hw1
        ToDoMVCTest
    hw2
        ToDoMVCTest

    И посмотреть будет просто - что делала в предыдущих работах
    и решишь проблему с неймингом
    в разных пекеджах одного проекта могут быть классы с одинаковыми именами
    потому - именуя классы в домашних работах - будешь руководствоваться все теми же правилами нейминга
    (см faq - там отличный раздел про нейминг, с кучей полезных линок)
*/
    @Test
    public void e2eSmokeTest() {
    /*
        тоже - посмотри на раздел по неймингу

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

        а вот этот совет - поможет
        https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#bookmark=id.2gjiy0o1o48q
    */
        open("https://todomvc4tasj.herokuapp.com/");

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

            лучше - отложить удаления тасок - на сымый конец сценария
            так тебе понадобится меньше тасок
            и тест будет эффективнее
            это важно)
        */
        tasks.shouldBe(empty);
        /*
            мы уже в прошлой работе - реализовали метод для такой проверки)
            используй
        */

        add("2");
        cancelEditTask("2", "3");
        /*
            интересно) - сравни имена методов - add и cancelEditTask
            почему в одном случае мы уточняемся до Task, а в других - нет? )
            я советую не уточняться)
            причина - а у нас все действия - только с тасками

            как переименовывать
            https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#bookmark=id.uaiq15o3yjor

            еще - используй тестовые данные для пояснения кода
            сравни
            cancelEdit("2", "3");
            и
            cancelEdit("2", "2 edit canceled");
        */
        editTask("2", "3");
        /*
            а что ж мы покрывать на других фильтрах?
            если все тут, на all покроем?
            а у нас еще и такая цель есть)

            предположим, на Completed фильтре перестали работать операции над тасками
            и вот если мы ничего там не покроем - то мы на этом этапе ничего и не узнаем
            понятно - мы и так можем не узнать - при равномерном распределении
            если именно не покрытая на данном фильтре операция отвалилась
            НО - вероятности мы улучним - вероятности - что поймаем такие проблемы
            ЕСЛИ - распределим по разным фильтрам операции поравномернее
            так что - таки придется это сделать) - равномернее распределить операции

            и вот это - сравни
            edit("2", "3");
            и
            edit("2", "2 edited");

            дальше - будет понятнее - что за таска, что с ней мы уже делали
        */

        complete("3");
        /*
            хм...
            ну, посмотрим на реализацию метода complete )
            пока выводы делать рано
        */
        assertTaskIsVisible("3");
        /*
            надо проверять состояние всего списка тасок
            а не только таски "3"
        */

        switchFilterTo("Completed");
        /*
            вот это почитай
            https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#bookmark=id.8bflixemdgfw

            и пересмотри реализацию переходов по фильтрам
        */
        //here I could avoid reopen and complete terminology and use "toggle" instead, but this way readability is better
        reopen("3");
        /*
            ага, вот и объяснение терминов)
            ну то позже обсудим

            смотри - было=стало
            было = в списке - таска 3
            перешли на Completed фильтр
            стало = в списке - таска 3

            так будет - даже если при переходе на фильтр ничего бы не делалось (вот такая ошибка)

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

            так что - переход в данный момент на Completed - не стоит делать)
        */
        assertTaskDisappears("3");
        /*
            нам не про таску "3" проверка нужна
            нам нужна проверка всего списка тасок

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

        switchFilterTo("Active");
        assertTaskIsVisible("3");

        completeAll();
        assertItemsLeft("0");
        /*
            слабовата проверка после completeAll() )
            нужно проверить список тасок
        */
        clearCompleted();
        tasks.shouldBe(empty);
    }
************************************************************
/*
    анализируем покрытие

    All
            add *2
            delete
            cancelEdit
            edit
            complete

    Completed
            reopen

    Active
            completeAll
            clearCompleted

    Единственное что не покрыли из высокоприоритетного - переход на all
    И не равномерно распределили операции (идеально не получится, но лучше - точно получится)
    И не точно проверили переход на Completed

    А так - много проработала)
*/
********************************************************
    ElementsCollection tasks = $$("#todo-list li");
/*
    тут и такой вариант селектора ок - т к приложение не сложное

    а было бы посложнее - было бы принципиально = "#todo-list>li"
    http://www.w3schools.com/cssref/css_selectors.asp
*/
*****************************************************************
    private void complete(String taskText) {
        tasks.findBy(exactText(taskText)).find(".toggle").click();
    }

    private void reopen(String taskText) {
        //this method implies task is already in completed state;
        complete(taskText);
    }
/*
    имя метода должно точно отражать то что он делает

    например
    примени метод complete к уже закомпличеной таске
    что получишь?
    таска закомплитится ?
    нет)

    значит - увы, точно = один метод = toggle
    имя которого четко описывает что он делает

    или - второй вариант
    в методы complete и reopen -
    первой строкой - встраиваем проверку состояния переключателя
    и второй строкой его кликаем

    что получим - метод будет или делать - что обещает в имени
    или будет падать)

    но тогда все же придется - строку - tasks.findBy(exactText(taskText)).find(".toggle").click();
    вынести в метод toggle
    и переиспользовать его в complete и reopen
    чтоб было DRY (посмотри в FAQ)

    вот такой вариант complete и reopen - не частій пример
    когда в методе-действии, внутри него
    есть проверка
    и она обеспечивает корректность выполнения действия
    а не проверки теста, как такового

    ну и сравни эффективность - toggle и варианта с complete и reopen )
    аскетичный toggle в данном случае будет эффективнее)

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

    ну, допустим, тут = разрулили)
    а вот для completeAll()vs reopenAll() vs toggleAll() - уже номер посложнее)
*/
*********************************************************************
    private void completeAll() {
        $("#toggle-all").click();
    }
/*
    выше писала)
*/
********************************************
    private void assertItemsLeft(String itemsLeft) {
        $("#todo-count").equals(itemsLeft);
    }
/*
    посмотри - что за сигнатура у метода equals)

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

    а также погугли java objects equals )

    нам нужна проверка
    которая - в случае ее невыполнения - обеспечит нам падение теста

    это - should-метод элемента или коллекции)

    имя и тип параметра
    itemsLeft - мы уже это написали в имени метода
    повторяться смысла нет
    можно кратко - count
    можно подробно - activeTasksCount
    в любом случае - мы что-то добавили к смыслу имени метода
    что хорошо)

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

*/
************************************************
    private void cancelEditTask(String initText, String newText) {
        tasks.findBy(exactText(initText)).doubleClick();
        tasks.findBy(cssClass("editing")).find(".edit").setValue(newText).pressEscape();
    }

    private void editTask(String initText, String newText) {
        tasks.findBy(exactText(initText)).click();
        tasks.findBy(exactText(initText)).doubleClick();
        tasks.findBy(cssClass("editing")).find(".edit").setValue(newText).pressEnter();
    }
/*
    ну, тут тоже получается - от контекста вызова будет зависеть - все ок будет
    или не ок

    если вызовешь
    cancelEditTask, а потом editTask
    то ок
    а если наоборот?

    работа метода не может зависеть от контекста
    или в оба метода встрой tasks.findBy(exactText(initText)).click();
    или убери эту строку вообще (я за такой вариант)

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

     имена параметров

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

        old & new - хороший вариант чтоб показать было-стало

        получим - oldTaskText & newTaskText

        еще - посмотри на код этих методов
        отличий - немного
        делаем код более DRY

        реализуй метод xxx который будет возвращать SelenideElement = элемент
        в котором мы указали новый текст

        и потом будешь его переиспользовать как xxx(.....).pressEnter();

        подумай над именем метода
        чтоб оно отражало - что метод делает
        фактически - он лишь начинает/стартует редактирование
*/
****************************************************************
    private void assertTaskIsVisible(String taskText) {
        tasks.findBy(exactText(taskText)).is(visible);
    }
/*
    метод is - просто вернет да или нет (true/false)
    тест не упадет - в любом случае

    а нам нужно - чтоб проверки в тесте - если они не прошли
    обеспечивали падения теста

    тебе нужны should-методы - для проверок

    и проверяй весь список тасок
    а не только одну какую-то таску

    там, конечно, тоже есть над чем подумать)
    для Active & Completed фильтров
    просто проверить тексты тасок  - не получится)
        посмотри в FireBug - что в списке тасок на разных фильтрах
        http://joxi.ru/l2ZNaR0F83gJv2
        Посмотри видео Якова про это - https://drive.google.com/file/d/0B8hgIBw8-V-AdGxxU1R3enl1RzQ/view?ts=567ab8d7

*/
*****************************************
    private void switchFilterTo(String filterName) {
        filters.findBy(exactText(filterName)).click();
    }
/*
    Писала выше про это)
    нужна KISS реализация

    про KISS - тоже все в FAQ почитай)

    и еще - т к линок у нас немного в приложении
    можно и попроще доступиться к ним
    не filters.findBy(exactText(filterName))
    а $(By.linkText(....))

    а в более сложном случае - твой вариант лучше
*/
*****************************************
    private void assertTaskDisappears(String taskText) {
        tasks.findBy(exactText(taskText)).should(disappear);
    }
/*
    ну, тут should - и это обеспечит правильное поведение метода-проверки)

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