==================================================================================================
1. "зачем удалять файлы - если  - mvn clean - прекрасно зачищает все это"

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

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

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

    но вообще - я считаю - не стоит оно того, ни в каком варианте)
*/
==================================================================================================
2. "public PreConditionsBuilder tasks(TaskType taskType, String... taskNames) {
            /*
                при такой реализации метода - не получишь цепочки тасок
                 закомпличеная а
                 активная b
                 закомпличеная с"

            >>>>>>>> в смысле не получишь?

                            givenAtTodoMvc()
                                    .tasks(TaskType.ACTIVE, "1")
                                    .tasks(TaskType.COMPLETED, "compl2")
                                    .tasks(TaskType.ACTIVE, "3")
                                    .filter(FilterType.ACTIVE)
                                    .buildPreConditions();
/*
    т е - в списке тасок будут вот такие таски именно вот в такой последовательности?
    активная 1
    закомпличеная compl2
    активная 3

    судя по старому коду - нет)
    а должно быть именно так
*/
==================================================================================================
3. "да и  switch  - не знаю
    мне кажется - решение было бы аккуратнее внутри и проще снаружи
    если бы мы могли вызывать
    ...comlpeledTasks("a", "b").activeTasks("c", "d").completedTasks("e", "f")
    и получать таски - в нужном нам состоянии и именно в такой последовательности"

            >>>>>>>> ну проще да, было бы 2 метода вместо одного) ну это то о чем я говорил, что
                    немного по другому реализовал, мне показалось так тоже удобно, что тебе сразу
                    подсказывают что ты можешь добавить стоит тебе написать TaskType.

                    сделать как ты предложила - это критично? я не вижу недостатков явных в своем
                    варианте, разве что в твоем можно от TaskType избавится класса вообще, но он
                    может в дальнейшем понадобится, так что не знаю даже)
/*
    Это очень похоже на ситуацию - когда мы реализовывали 3 метода для переходов на каждый фильтр, а не один
    И в фак это рассмотрено
    https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#bookmark=id.8bflixemdgfw

    когда речь шла о простом варианте решения - просто о наборе гивен-методов - таки да, наверное, правильнее было использовать параметры
    можно было все свести к вариантам
        given(Filter filter, Task... tasks)
        given(Filter filter, TaskType taskType, String... taskTexts)
    или к 6 методам - если фильтр не передавать как параметр, а реализовівать гивені для каждого из фильтров

    у тебя - решение позволяет сделать KISS вариант
    причем - все сложности будут под капотом
    тот кто будет вызывать билдер для гивенов -
    указывает имя метода
    ставит точку
    и видит набор методов
    сравнительно не большой
    с очень простым набором параметров
    мы в таком случае - можем вообще людей не прогружать - наличием типов Filter filter и TaskType taskType
    там, где-то глубоко внутри - они вполне могут быть
    но - зачем знать это тем, кто просто юзает решение
    им надо выдать инструменты, желательно - максимально простые, удобные и наглядные

    в тестировании - это важно - чтобы код был KISS
    важнее чем при разработке ПО
    этот вроде бы простой момент - в голове укладывается плохо поначалу)
    но потом - доходит - в чем тут плюсы
*/
==================================================================================================
4. "минимально к ревью
             - упрости решение
             - не лови null pointer exception
             - уйди от мутабельности
             - не убивай файлы
             - не лови IOException

         максимально к ревью (можно не делать, это только если видишь практическую пользу для себя)
             - аттачить как скриншот так и ???html - если он сформировался)
             - возможность аттачить на любом степе теста (это не сложно - вызывай в степ-методе - метод с аннотацией Attachment)"

                >>>>>>>> сразу общий ответ по всем репортам:

                        1. html генерит screenshot(), takeScreenshotAsFIle() - нет, так что нужно
                            только первый вариант использовать http://prntscr.com/duqlg3
                        /*
                            ну да, если есть цель аттачить и html - тогда да)
                        */

                        2. Переделал полностью AllureScreenPublisher -> AllurePublisher (т.к. он уже не только скрины паблишит), обрати внимание:

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

                                 @Rule
                                 public AllurePublisher publishHtmlonFail = AllurePublisher.onFail().saveHtml();

                                 @Rule
                                 public AllurePublisher publishScreenOnSuccess = AllurePublisher.onSuccess().saveScreens();

                                 @Rule
                                 public AllurePublisher publishScreensAndHtmlAlways = AllurePublisher.always().saveScreenAndHtml();

                                (кстати можно несколько сразу включать, например 1-й и 2-й, абалдеть крутота :D )

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

                             -- чистка после паблиша конфигурируема
                             /*
                                ну я писала тебе - я б не тратилась)

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

                             -- ловлю IOException, потому что:
                                    * если он вдруг начнет лететь, заглушит Throwable в случае падающего теста
                                    * это checked exception, а правила методов failed() и succeeded() не позволяют добавлять к сигнатуре throws

                             -- кидаю AssertionError для того чтобы если вдруг что то отвалится, тесты упали. Если тест успешный - вылетает,
                                если падающий - добавляю к тому что летело что мол еще и скрины отвалились
                             /*
                                ок, все логично)
                             */

                        3. Добавил класс AllureHelper, в нем методы publishHtml() и publishScreenshot(), можно вызывать в любой момент теста
                            работает: http://prntscr.com/dus2ld
                            /*
                                тоже красиво все
                                подумай - как заюзать в AllurePublisher - AllureHelper
                                чтоб уйти от дублирования кода
                                и облегчить AllurePublisher
                                т е - AllureHelper - умеет гененить и аттачить скриншоты/html
                                AllurePublisher - умеет это вызывать когда нужно

                                будет очень хорошо)
                            */
==================================================================================================
5. "public class SmokeTodoMVCTest
    /*
        объединять тесты для Smoke покрытия в одном тест-классе - не свегда удачная идея
        часто - удобнее - когда тесты собраны по тест-классам тематически
        и некоторые из них - составляют смоук покрытие
        это скоро научимся делать

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

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

        в каждом тест-методе - используй гивен-методы

        хм....
        смотрю на другие тест-классы - похоже ты так и сделал
        а это - с прошлого задания тест-класс

        если так - все равно переименуй тест-класс в TodoMVCTest
        и расположи в правильном пекедже - где ты предыдущие задания собираешь
        как для предыдущего задания - с ним все ок
    */"

            >>>>>>>> а то что тесты содержат smoke логику не объединение по тематике?

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

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

    так лучше на практике

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

    как раз это категориями и задается - покрытие
*/
==================================================================================================
6. ""    идеально наверное, вообще вот так -
            page.itemsLeft().shouldBe(...)

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

            щас - не буду спорить"

                >>>>>>>> я не силен в ООП в джаве пока, ума хватило только на такую реализацию.
                        посмотри пожалуйста, так нормально реализовано?
    /*
        все ок в общем-то
        стоило ли делать иннер-классом - а не знаю)
        может в данном случае и стоило)"

            >>>>>>>> ну если мы хотим иметь возможность в цепочки объеденять эту проверку,
                    то как без иннер-класса - я хз
/*
    дождись виджетов, там разберем
*/
==================================================================================================
7. "    нормально подрубиться к ScreenShooter - не выйдет)
        причину - ты хорошо описал)
        возможно - можно отнаследоваться от ScreenShooter
        и что-то там дописать в потомке
        но я не вижу острой необходимости так делать

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

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

                    ScreeShooter - отнаследоватся нельзя, конструктор приватный
/*
    уже твое решение - крутое

    а если еще сделать код более DRY
    и более четко обозначить ответственности Helper & Publisher
    будет идеально
*/
==================================================================================================
8. "    Прятать создание пейджей в предке тест-класса - не хорошая практика,
        особенно в общем случае - когда у нас несколько пейджей

        На самом деле - для разных тест-классов - может понадобиться разный набор пейджей
        Потому - создавать весь набор инструментов - вроде как перебор

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

        Вот если использовать некую одну точку входа - тут создавать некий объект
        с помощью которого можно будет получить доступ к любым пейджам - так оно будет более оправдано
        Если, конечно, пейджей больше одного)
        Да и создание такой точки входа - лучше вынести в отдельный предок тест-класса
        тк  - Single Responsibility principle

        Почитай вот тут - диалог Якова и студента, который аналогичное решение применял
        http://pastebin.com/qP85P1SP
        думаю, вопросы должны отпасть

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

            >>>>>>>> согласен, в предка создание пейджи прятать было глупо.

                    из диалога не понял ровным счетом нихрена)

                    кто что предлагает, что вообще происходит, какие контейнеры, какие предки...

                    когда вариант объявлять страницы полями в классе перестал быть достаточным?

                    идея в том чтоб каждый раз не писать с какими страницами работа? в каждом тест классе?
                    так тогда в каждом жеж тесте будет что то типа pages.taskPage или Pages.taskPage если
                    делать отдельный класс...

                    а если страница длинно называется, типа как taskWithVeryDifficultFlowPage в тесте
                    прямо так и писать эту колбасу?

                    не понял кароче о чем спор вообще)
/*
    Вот студент настаивал - что надо спрятать создание пейджей в предке тест-класса
    чтоб типа не засорять екод тест-классов

    вот о чем спор)

    привела - т к у тебя было реализовано создание пейджи - в предке тест-класса
*/
==================================================================================================
10. "    ясно

         я писала выше - тут вообще стоит location.reload() делать
         после таких открытий - сразу на урле фильтра
         как показал опыт - самое надежное решение"

                >>>>>>>> неа, все равно падают. оставляю селениумский refresh()

                        кстати, а чего вдруг селенидовский рефреш совсем не рефреш, в чем прикол?
/*
    про селенидовский рефреш - первое что делай - когда вопрос возникает - смотри исходники
    вот посмотри например на код open  - https://github.com/codeborne/selenide/blob/master/src/main/java/com/codeborne/selenide/impl/Navigator.java
    там куча вариантов
    в том числе - и странички, открываемые локально

    думаю, текущая реализация рефреша - наиболее универсальна в таких обстоятельствах
    это моя гипотеза)
*/
==================================================================================================
11. "    @Test
         public void clearCompleted() {
             givenAtTodoMvc()
                     .tasks(TaskType.ACTIVE, "1")
                     .tasks(TaskType.COMPLETED, "compl2")
                     .filter(FilterType.ACTIVE)
                     .buildPreConditions();

             page.clearCompleted();
             // TODO how to check it with existing functional ?
         }
     /*
         проверь тексты тасок и итемс лефт

         этого будет достаточно

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

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

         если не нравится идея
         можно монизить приоритет clearCompleted на эктив фильтре до среднего и не покрывать

         или - придумать - как реализовать маленький е2е
         в котором что-то еще проверить
         и уточнить то - что нам нужно

         я за первый вариант

         то же касается и других твоих похожих вопросов (то что ты оранжевым в тест-плане выделил)"

        >>>>>>>> скрипя сердцем добавил маленькие е2е в те места, т.к. другой возможности нормально
                проверить не знаю...

                с твоими предложениями по поводу приоритета и косвенных выводов - не согласен)
/*
    не буду спорить)
    когда-то и я с Яковом не соглашалась в этом вопросе)

    теперь соглашаюсь)
    просто держала в голове - что есть еще и такой подход

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

    а поначалу никак не могла согласиться)
*/
==================================================================================================