@After
    public void afterMethod() {
        clearLS();
        getWebDriver().navigate().refresh();
    }
/*
    спорно - стоило ли выносить в отельный метод clearLS() - очистку локалсториджа
    да еще и в имени метода - сокращать слова

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

    насчет рефреша
    в selenide - есть метод refresh()
    технически - то же самое
    просто лаконичнее

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

    в более ранних версиях todoMVC приложения - такой рефреш был нужен
    теперь - нет

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

    получим:
*/
    @Before
    public void visit() {
        page.visit();
    }

    @After
    public void clearData() {
        executeJavaScript("localStorage.clear();");
    }
********************************************************
    @Test
    public void editEnterAll() {

        //given
        page.add("1")
                .toggle("1")
                .goCompleted();

        // test
        page.editEnter("1", "edited1")
                .shouldHave("edited1")
                .shouldBeItemsLeft(0);
    }
/*
    editEnter - не лучшее описание действия

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

    проверяем - на Completed фильтре
    стоит перед именем фильра - использовать предлог At/On - чтоб подчеркнуть -
        что речь о фильтре
        о том - где мы это делаем

    так что - правим название тест-метода и вспомогательного метода

    и до кучи - избавляемся от комментария // test
    т к - где гивен-блок, а где остальное - и так ясно
    благодаря пропущенной строке и комментарию //given

    получим:
*/
    @Test
    public void editAtCompleted() {

        //given
        page.add("1")
                .toggle("1")
                .goCompleted();

        page.edit("1", "edited1")
                .shouldHave("edited1")
                .shouldBeItemsLeft(0);
    }
************************************************
    editCancel
/*
    термин editCancel - не удачный

    обычно - имя метода = глагол(что делаем)+уточнения
    мы - отменяем редактирование = cancelEdit

    если хочется подчеркнуть последовательность действий
    то startEditThenCancel
*/
******************************************
/*
    что хорошо - что в фиче-тестах -
    ты использовал разные тестовые ситуации
    это очень полезно в плане покрытия

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

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

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

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

    крутой, что сказать)
*/
*************************************************************
===================================================================
1. "вместо того, чтоб заводить переменную editingTask
   ....

            >>>>>>>> гениально!
/*
    ага
    и очень просто)
*/
===================================================================
2. "сравни $(".editing .edit")
    и tasks.findBy(...).find(...)
    во втором случае - суть длиннее
    но - нагляднее и понятнее - с чем мы работаем"

        >>>>>>>> гениально! не додумался...
/*
    обязательно масштабируй этот момент
    выручает и сильно

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

    самые неожиданные выгоды от этого подхода получаю)
*/
===================================================================
3. "сравни
    shouldBeItemsLeft
    shouldItemsLeft
    мне кажется - второй вариант - попонятнее
    ?"

        >>>>>>>> с точки зрения англ shouldBe должен быть, да и как
                по мне понятнее все таки shouldBe, нежели should
/*
    идеально наверное, вообще вот так -
    page.itemsLeft().shouldBe(...)

    ну то потом так напишем)

    щас - не буду спорить
*/
===================================================================
4. "по первым строчкам методов
    т к приложение простенькое - можно вполне обойтись вариантом
    $(By.linkText(...))
    для приложения посложнее я бы применяла
    $$("#filters>li").findBy(exactText("..."))
    а т к $$("#filters>li") - повторялся бы трижды
    то вынесла бы $$("#filters>li") - в переменную пейджа"

        >>>>>>>> гениально! это сразу столько проблем решает...
                чет я как то туплю маленько :\
/*
    это можно научиться видеть
    ты так точно научишься )
*/
===================================================================
5. " public TaskPage goCompleted() {
             $("#filters>li:nth-of-type(3)>a").click();
             tasks = $$("#todo-list>li.completed");
             return this;
         }

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

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

    как оказалось - очень удобно immutable свойства объекта сразу final объявлять
    потом Idea - сама подсказывает, что тоже снимает часть вопросов)
*/
===================================================================
6. "чтоб потом вызывать такой метод
        startEdit(fromTaskName, toTaskName).pressEnter();"

            >>>>>>>> гениально! опять)
/*
    вот этот подход - мы чуть позже - разовьем и усугубим)

    сейчас - мы просто повторяющиеся действия вынесли в отдельный метод

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

    это так, спойлер пока)

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

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

*/
===================================================================
7. "имена методов
        editEnter - я бы в данном случае - не уточнялась до энтера - т к это стандартная реализация редактирования
        как доберемся до автоматизации additional edit operations - там уже будем уточняться"

            >>>>>>>> я уточнил до энтера потому что у нас не
                    один метод edit, уже. а будет больше)
/*
    про энтер - как раз можно и не уточняться
    типа - дефолтное поведение - и так ясно

    ну и варианты тут есть для additional edit operations
    confirmEditByPressTab
    confirmEditByClickOutside
    deleteByEmptyingText

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

    думаю - начинать с главного=что делаем и лишь потом уточняться=как делаем
    более выигрышная стратегия для имен методов
*/
===================================================================
8. " editCancel - тоже с недостатками
            что мы делаем = отменяем редактирование = cancelEdit
            а если хочется подчеркнуть последовательность действий - startEditThenCancel
            что-то такое"

                >>>>>>>> назвал начиная с edit чтоб можно было в тесте
                        писать .edit и идея подсказывала бы все
                        варианты, проще было бы) ну и это в принципе
                        суб-функционал edit-а, поэтому и название
                        начинается с edit
/*
    выше описала варианты

    мой фаворит - cancelEdit
    от общего к частному)
*/
===================================================================
8. "по тест-плану

    https://docs.google.com/spreadsheets/d/1eAw67UrF58vyCf0Fk7f9hzoFFICgkeYVhhrph4XSb5g/edit#gid=0

    /*
        мы - по-прежнему - планируем smoke
        это значит покрываем только высокоприоритетное и ТОЛЬКО на одном контексте

        и еще - один фиче-тест - проверяет одну фичу
        лишь одну

        фактически - разгрузив наш е2е (что ты успешно сделал)
        надо было допокрыть фиче-тестами
        http://joxi.ru/Rmzqpx8H00kn1r
        3 штуки - для каждого действия
        и в рамках проверок в фиче-тестах - второй проверкой - покрой проверку items left
        просто потому что по пути и это почти ничег не стоит

        у тебя реализованы - не фиче-тесты
        а небольшие е2е тесты
        учти по оформлению фиче-тестов"

            >>>>>>>> так хотелось покрыть побольше... ну ладно, смоук так смоук)
                    изменил в плане в и коде
/*
    будет тебе и полное покрытие)
    не торопись)
*/
===================================================================
8. еще такой вопрос по поводу

    public TaskPage shouldBeItemsLeft(int itemsCount) {
        $("#todo-count>strong").shouldHave(exactText(String.valueOf(itemsCount)));
        return this;
    }

    получается в зависимости от того есть ли таски или нет, проверка
    shouldBeItemsCount(0) должна по разному работать (или в элементе 0,
    или вообще футера нет). это нужно сейчас реализовывать?
/*
    видим футер или нет - такой функционал, не очень-то приоритетный
    даже если футер окажется видим, когда не должен быть видимым - потеря небольшая )
    приложение все еще можно успешно юзать

    проверяя - $("#todo-count>strong").shouldHave(exactText(...
    мы косвенно проверяем - что футер видим

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

    а если б стала - то не запихивала в этот метод варианты
    а написала отдельно assertFooterIsInvisible
    и отдельно в тест-методе такую проверку уместно вызывала

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

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

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

    еще вариант
    наверное - ты уже видел в видео
    когда Яков предлагает проверять не видимость кнопки clear Completed
    после нажатия на нее - прямо внутри метода  clearCompleted
    такой вариант допустим, когда
        этот нюанс - не важен
        и нам не нужно его анализировать на уровне тест-методов

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

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

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

         а были бы отягчающие - использовала бы вариант "кишки наружу" )

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

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

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


*/
===================================================================