========================================================================================================================
        >>>>>>>> предлагаешь писать что то типа

                THEN().atInboxPage()
                .emails()
                .shouldHave(size(1));

                ?

                >>>>>>>> не, предлагаю писать:

                        THEN().atInboxPage()
                        .emails()
                        .shouldHaveTopics(topic);

                        // и оно должно проверить что топиков ровно один и ровно с таким текстом в списке...
                         ну точно также как и в селениде работает shouldHave(exactTexts(topic)) если бы emails
                         возвращали ElementsCollection а не виджет

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


                        >>>>> не, ну вы сударь изрващенец-с...

                        зацени, твой вариант:


    public Emails shouldHaveTopics(String... texts) {
        mails.shouldHaveSize(texts.length);
        for (int i = 0; i < texts.length; i++) {
            get(i).shouldHaveTopic(texts[i]);
        }
        return this;
    }

                        и тот на который я тебе намекал:


    public Emails shouldHaveTopics(String... texts) {
        mails.shouldHave(texts(texts));
        return this;
    }

                        мне не понятно зачем городить фор, если он уже встроен внутрь кондишена CollectionCondition.texts
========================================================================================================================
    /*
        ты таки не всегда используешь проверку Tasks.itemsLeftShouldBe(...); - даже если это воможно
        а она ведь - уточняет проверки и улучшает покрытие

        и почти не усложняет фиче-тестов

        почему?
    */"

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

                    получается тест вроде как тестирует edit, destroy, add....а упали все сразу, да еще и с
                    ошибкой should be items left.

                    >>>>>>>> да, мужик, замечательный аргумент :) Правильно мыслишь. Но :) Дело в том, что со стороны разработки, это работает не так... Эта фича - каунтера - она будет размазана по коду... Оно не реализована где то отдельно... Она будет разбита на количество "подфич" - привязанных к действиям соответствующим. И в реальной жизни будет так, что где то для какого то действия = девелопер забудет "учесть подфичу каунтера" - и тест к этому действию упадет - и упадет правильно - указывая для какого именно действия "подфича каунтера" не сработала. А другие тесты будут проходить. Возможно если бы ты знал как работает фронтенд, то ты это учел. И кстати именно поэтому, нужно что бы девы писали аксептенс тесты а не автоматизаторы ;) Но ты конечно молодец что подумал об этом нюансе, даже очень :) Ты первый студент из всех кто об этом задумался, даже пускай и оно привело тебя к неверным решениям :)

            >>>>>>>> есть план в google sheet, где было распланировано что мол фича itemsLeft
                    должна быть протестирована в местах высокого приоритета (add, destroy)
                    на всех контекстах, в местах низкого (переход между фильтрами, еще что то)
                    только на одном из фильтров (постаратся нужно было чтоб было размазано по
                    всем поровну, я старался)), что и было сделано =)

                    Юля настаивала что мол нам ничего не стоит проверить items left в фича тестах,
                    а я не хотел, и аргумент вот как написал) и до сих пор так считаю, не надо
                    тулить абы натулить, если проверять уже эту фичу всеобъемлюще, то делать это
                    организованно, а не рандомно разбрасывая проверки по тестам не для этого написанным)


                    >>>>>> чувак, ты не понял. Фича items left - это не фича сама по себе. Это технически 7 или сколько там подфич фич действий. Раставлять проверки каунтера - это не рандомно раставлять - а там где нужно. Проверка каунтера - это часть проверки действия. В гугл шите эти "подфичи" были отдельно только потому что будучи подфичами - они меньшего приоритета... и поэтому можно было не спешить их раставлять в тестах. А когда мы уже перешли к "полному покрытию" - мы их "не рандомно раставили" - а дописали туда где им и место. У меня мозг плывет от твоего "тулить абы тулить". Ты что реально не понимаешь что проверить каунтер для ед таскас, это то же что проверить что задача добавилась? тольк типа "еще одна дополнительная проверка меньшего приоритета". Еще раз - каунтер - это не отдельная фича - это комплекс отедльных подфич которые являются частями фич действий. И поэтому абсолютно логично их проверять там же где и проверяются эти "основные" фичи. есть такое понятие как cohesion в программировании. Которое говорит о том - что связанные вещи должны быть вместе. В контексте системного тестирования поведение каунтера под действие связано с действием. Поэтому это прямой идентификатор "должно быть вместе", и "тулить где попало" - это тут совсем не причем. наоборот - тулить туда где ему и место и по логике поведения пользователя, и по внутренней реализации. Если бы мы писали юнит тесты - там все дробиться как можно меньше.. И там были бы отдельные тесты на добавление задачи в список, и отдельное на каунтер... При этом каунтер бы проверялся даже не через дейсвие, а через искуственно созданный ивент, или еще чего там такого... там бы пришлось симулировать эффекти добавления, реально его не делая... потому что такая уж философия у юнит тестов - вс тестировать раздельно всегда... Но системные тесты - на то и системные что бы тестировать "как оно работает" вместе, особенно учитывая то что каунтер - это часть действия а не отдельная от него вещь.
========================================================================================================================
    @Step
    public static ItemsLeft itemsLeft() {
        return new ItemsLeft();
    }

    public static class ItemsLeft {
        private static final SelenideElement element = $("#todo-count>strong");

        public void shouldBe(int itemsCount) {
            element.shouldHave(exactText(String.valueOf(itemsCount)));
        }
    }

вот тудуемвісі - это пример того приложения где виджеты имхо - это перебор :)

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

но тогда если уж "тренироваться" - то наверное стоило бы вынести отдельный виджет Task :)

да и еще такой нюанс...

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

но с другой стороны у нас "запахло Large Class Code Smell"... и типа как "проще" и более понятней, было разложить нашу кучу большую на маленькие в разных местах, а не разложить кучу на кучки по меньше запхать самые маленькие кучки в мешки и положить в мешок с самой больешой кучей внутрь :)

Ну такое... смотри сам...

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

                >>> ну... не знаю... по твоим же линкам ходил и нашел... где то :)

                приложение маленькое, и учитывая что этот класс может пригодится
                ТОЛЬКО в классе Tasks, то как бы вроде и не надо выносить отдельно,
                если этот класс используется только в контексте другого, а
                самостоятельно он существовать не может)

                >>>>>  я же тебе тоже самое по сути и написал... что можно и так и так... и "смотри сам"
========================================================================================================================
а когда нужно писать:

new WebDriverWait(...).until(jsReturnedTrue("return $._data($('#clear-completed').get(0), 'events').hasOwnProperty('click')"))

        >>>>>>>> не понял что ты тут делаешь) вообще ниче не понял, кроме того что текущая реализация
                может при медленном интернете падать))


========================================================================================================================
вижу ты хромдрайвер держишь в проекте :)
помню Юля уже "жаловалась на тебя" :)
Ну ок, делаешь как хочешь. Но знай, что этим ты перечеркиваешь весь тот путь которым идет Селениум :) То есть ты как бы "споришь с авторами селениума" :)
Значешь почему теперь нет FirefoxDriver ? А есть марионет в виде бинарника ?
Только по одной причине :)
Что бы не зависеть от исходных сорсов :)

        >>>>>>>> помню помню, спорили)

                в чем дело было, в двух словах:

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

                    >>>> это реашется простющим скриптом который посылает реквест серверу с хромом и проверяет появилась ли новая версия... и обновляет ее, если локально и хром более новый стоит... где то вот тут можно например на питоне примеры найти: https://github.com/SergeyPirogov/webdriver_manager/blob/master/webdriver_manager/driver.py

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

                но все таки одумался, если вдруг у вас еще будут такие же бараны, то вот аргумент который меня убедил на 100%:

                - хромдрайвер нужен для БРАУЗЕРА по сути, а не для тестов, в них мы его возможности нигде не используем,
                  а раз такое дело, значит он ближе к браузеру, чем к проекту с тестами, т.к. проекты могут быть разные,
                  а хром и хромдрайвер одни на всех будут, а значит их и хранить нужно отдельно


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

                не сразу я понял, но лучше поздно, чем никогда :)

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


                    >>>>>>> да че, виртуалки это еще норм) я бы просто скрипт написал который все делает сам а не руками... но если сейчас все работает, и все привыкли то пускай конечно и будет так...
========================================================================================================================
Зачем тебе DefaultFail категория с тестом? :)
Ты конечно шаришь :) Я знаю для чего нужен этот трюк, но хочется услышать от тебя обьяснение :)
Я просто не знаю, вы с Юлей говорили об этом уже или нет...

        >>>>>>>> говорили, не то чтоб ей очень эта идея понравилась, но и настаивать на полном её удалении не стала)

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

                а так сразу все упало и сказало тебе, что мол ты дружище что то напортачил, проверь конфигурации)



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


========================================================================================================================
мне кстати не совсем нравиться твоя идея называть "пакет куда ты складываешь полезняшки" как api...
оно просто конфузит слегка... к чему АПИ? :)

причем иногда ты называешь так часть которая относится к тест модели - здесь апи как раз подходит...
а иногда часть которая как раз "полезняшки" - типа кастомкондишенов и так дале...

ну такое... не уверен знаю ли я лучшее имя... мы обычно называем как core полезняшки
еще есть практика называть common

а тестовую модель я называю model... но в этом случае и api подойдет...

        >>>>>>>> мне просто нравится как это звучит, и пишется :)

                можно core назвать, возможно оно лучше подходит под описание...
                common не нравится, получается что у меня тогда будет верхний коммон, и коммон todomvc, и коммон gmail...
                так себе)

                >>>>>>> так в том то и фишка, что не будет... в тех слоях что вертикальные - вверху будет common (или core) а внутри (для todomvc) будет model ну или api - тут как раз оно подходит....
                а в паралельных слоях если будет одинаково - то тоже ок, оно ведь там будет только потому что ты в один проект все налепил... в реальных случаях оно бы в разных проектах было бы скорее всего... да и вообще - для паралельных слоев - оно норм если бы одинаково называлось... пейджобджектс же также и там и там есть...

                а по поводу model я не совсем понял, поясни пожалуйста)

                >>>>>>>> ну то что у тебя api для todomvc - это по сути "вход в модель тестового приложения...." поэтому я бы так его и назвал... с другой стороны пейджобджекты тоже часть модели приложения... поэтому я иногда делаю такую структуру:
                model/pageobjects/...
                model/Application.java


========================================================================================================================
public class Application {

    @Step
    public InboxPageObjects atInboxPage() {
        return new InboxPageObjects();

        // мне не совсем понятно почему InboxPageObjects ? почему не InboxPage или Inbox?
        // ты же вот почему то не назвал ApplicationPageObjects?
        // есть такое понятие как контекст. Если он задан то зачем каждый раз напоминать что я Яша Украинец?
        // У меня и так в паспорте написано что я из украины. Я о том что создай один пакет, назови его pageobjects, или как тебе больше нравиться и потом уже незачем повторять в каждом имени класса это PageObjects. И так понятно что оно такое.
    }

            >>>>>>>> ApplicationPageObjects не назвал потому что класс Application олицетворяет собой все приложение,
                    а не кучку html-elements и "виджетов" :)

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

                    >>>> Зачем, мы же в реальной жизни так не делаем? я тебе с Яшей Украинцем вон привел пример... Зачем быть многословным там где и так все достаточно очевидно...

                    если назвать InboxPage то получается что я буду отличать pageobjects высокого уровня от тех что пониже
                    только приставкой Page... и опять вернусь к тому с чего начал)

                    >>>>  к чему вернешься?? что не так... те что полные страници - те с приставкой Page, те что "части страниц, то есть виджеты" - те без. Помоему норм подход. Все различается, что еще нужно? Хотя я сам забил на все эти приставки, мне и так все очевидно. Для мени с точки зрения юзера не важно что то страница или нет, потому что я сам как юзер - не говорю - зайди на фейсбуке на страницу сообщений. Я просто говорю - зайди в сообщения, и точка :)

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

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

                    >>>> смотри смотри :)
========================================================================================================================
        $(".cmsg").waitUntil(hidden, 15_000);
        // во первых плохо хардкодить вейты... лучше напиши Configuration.timeout * 3, что бы ты мог их конфигурировать где нужно...
        // во вторых -  зачем этот вейт здесь? степы не должны проверять результат своих действий... сделал дело гуляй смело... следующий степ должен сам уметь подождать чего там ему нужно... ты вот, мне кажется, вообще начал неблагодарное дело... "точечно вейты раставлять", лучше поставть глобальный таймаут равный 15000 и тогда все и так будет работать. когда ты захочешь кликнуть по кнопке компоуз - оно и так подождет 15 секунд пока она появится... Или ты так пробовал и жмейл у тебя все равно фокусы выкидывал?
        Точечно имеет смысл раставлять вейты когда - таких тормознутых мест мало... а жмейл этот один весь сплошной тормоз :) я бы нем лучше глобальный таймаут поставил...

            >>>>>>>> тут буду спорить :)

                    по поводу хардкодить вейты - а в чем собственно проблема? если я знаю, что именно вот тут в приложухе
                            все медленно, то почему не поставить точечное ожидание, больше чем обычное?
                            Configuration.timeout * 3 - не уверен что это лучше, т.к. если вдруг этот момент растянется
                            на 20,25 секунд то что, увиличивать из за него общий таймаут? смысл точечного вейты заключается
                            как раз в том, что есть конкретное место, которое отличается от других, и в тестах это отражается
                            в виде отдельного вейта)

                            >>>>  не, именно тут даже спорить не о чем. Configuration.timeout * 3 лучше, потому что вот захардкодил ты 15 секунд. А твои тесты специально запустили на медленной машине, что бы проверить что там все также будет работать как надо, но зная что она медленная увеличили таймаут общий до 15 секунд. И все. Хана. Приложение стало ВЕЗДЕ тормозить в три раза больше... но никак повлиять на твое "захардкодженое место" - возможности нет. Именно поэтому если и раставлять где то точечные таймауты - то все равно делать их "относительными к какой то базе, которую можно конфигурировать".

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

                            >>>> твой аргумент с анимацие верный. Именно для таких случаев и с такой логикой - и стоит использовать точечные таймауты. Все верно. Но... С жмейлом другая ситуация. Анимация - это конкретный детерминированный случай. Лучше такие сразу "точечно определять и в тестах". Но жмейл - не детерминированный - он реально тормоз. Причем часто и много где. Поэтому с точки зрения эффективности - именно для этого приложения - ты сэкономишь больше времени как раз не на том что падающие тесты будут меньше времени занимать. А на том что не будешь в начале автматизации - заморачиваться с этими точечными вейтами... Потом, позже... У тебя появится какая то статистика, и ты действительно сможешь определить "стабильные тормоза" типа из твоего примера с анимацией. И тогда уже их раставить. Это именно то что я тебе сразу хотел обьяснить.

                    по поводу зачем этот вейт вообще - с одной стороны метод называется ensureLoggedAs(), т.е. во первых
                            из названия следует что он таки должен привести юзера в статус залогиненного, а чтобы в этом
                            убедится нужно подождать ошибку, или наоборот, подождать пока появися какой то элемент на
                            inbox page...
                            с другой стороны если в логине ошибка, то она должна вылетать из методы который собственно
                            сам логин и совершает, но не из метода inbox page, который уже хотел куда то там клацнуть, в
                            то время когда был все еще по факту на Login page...
                            согласен что вейт возможно не в самом удачном месте, но слово ensure покрывает такую бяку, в
                            этом конкретном случае)


                            >>>> да, согласен, именно изза того что это "еншеа" а не просто степ - то да, в нем асерт допустимый...

                            я правда не уверен что именно сдесь нужна эта "еншуерность", ну то такое...
========================================================================================================================
public class Emails {
    private final ElementsCollection mails;

    private Emails(ElementsCollection visibleMails) {
        this.mails = visibleMails;
    }

    public static Emails all() {
        return new Emails(
                $$(".Cp tr")  // вот этот локатор дублируется, возможно стоит его таки "заDRYить" вынеся его в стическую переменную

        >>>>>>>> возможно, но он используется почти в одном месте (3 метода рядышком), и я такой типа CopyAndReplace рулит,
                Яков на своих видосах говорил, зачем создавать поле если можно и так без проблем поменять локатор когда придется :)
                мне не мозолит, но могу вынести, если критично :)

                >>>> ну... для меня это таки уже не "рядышком" :) ну такое... все субьективно конечно... просто этот локатор сам по себе - не читабельный... я бы его вынес в переменную просто с целью дать ему красивое имя :)

                ну такое... может сдесь это и не сильно актуально, смотри сам...
========================================================================================================================
                        .filterBy(visible)
                        .filterBy(cssClass("zE"))

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

filterBy(and("visible and unreaded", visible, cssClass("zE")))
потому что так оно будет "один раз в цикле пробегаться по всем", а в твоем случае будет два раза пробегаться...

        >>>>>>>> ок, заменю, спасибо за подсказку)
                выглядит жутко, странно что селенид создал отдельный свой класс кондишен, но не прикрутил возможность
                писать filterBy(visible().and(cssClass())) или чет такое...

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

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

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


        THEN().atInboxPage()
                .emails()
                .get(1);

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


                >>>> ну я же сказал... "проще подучить людей что бы были чуть чуть как программисты чем везде где есть индексы - извращаться в коде" :)
                в общем... тут я переубеждать не буду... я когда то сам думал о том что бы так делать как ты... но передумал.

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