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

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


    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

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


            >>>>>> ну ну :) окей, а как тебе такой тогда вариант:

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

            ?

            если уж ты решил быть "таким точным" (что в принципе не плохая идея), то разве не стоит отдельно иметь topics вместо mails, и таки переиспользовать уже готовую реализацию цикла? а не с нуля ее писать...

            и если уж ты решил все делать так точно... то возможно достаточно было бы синтаксиса

        THEN().atInboxPage()
                .emails()
                .topics()
                .shouldBe(topic);

            вместо

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

            но может это уже будет перебор... скорее сдесь это не нужно... будет пока что лишнее усложнение реализации...

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

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

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

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



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

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

                если бы ты передавал например параметр -Dtest то он вроде по умолчанию заранит вообще все тесты в проекте)

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

                а ты зачем использовал, для мониторинга покрытия? :)

                    >>>>> я бы использовал похожий подход с той целью что бы в сьюте buggy всегда бил один тест который падает. Ибо идея сьюта багги в том, что бы на него завязать джобу в дженкинсе которая всегда будет падать со всеми тестами... и если все тесты падают - тогда имейл не приходит команде - сигнализируя о том что все хорошо. В этом случае "все хорошо" - значит что все тесты падают как и ожидается - на них есть ишью в джире - и мы просто еще не планировали их фиксить... а если вдруг какой то тест начинает проходить - значит это сигнал - что что то поменялось и и должен прийте имейл - что мы обратили внимание, разобрались что по чем - может баг чудесным образом какой то сам пофиксился - и стоит его перепроверить и из джири удалить, убрать анотацию @buggy и успокоится. При такой схеме, когда все баги будут по фикшены - то эта джоба начнет "проходить а не падать" - и вся настройка по имейл нофификации поламается :) И типа что бы этого не было - нужно что бы в сьюте оставался всегда один тест который падает.
========================================================================================================================
>>>>>> чувак, ты не понял. Фича items left - это не фича сама по себе. Это технически 7 или сколько там подфич фич действий. Раставлять проверки каунтера - это не рандомно раставлять - а там где нужно.
Проверка каунтера - это часть проверки действия. В гугл шите эти "подфичи" были отдельно только потому что будучи подфичами - они меньшего приоритета... и поэтому можно было не спешить их раставлять в тестах. А когда мы уже перешли к "полному покрытию" - мы их "не рандомно раставили" - а дописали туда где им и место.

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

Которое говорит о том - что связанные вещи должны быть вместе. В контексте системного тестирования поведение каунтера под действие связано с действием. Поэтому это прямой идентификатор "должно быть вместе", и "тулить где попало" - это тут совсем не причем. наоборот - тулить туда где ему и место и по логике поведения пользователя, и по внутренней реализации.

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


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

                но я все еще не понимаю, зачем делать exhaustive testing ?

                    >>>> вся наша домашка full coverage - высосана из пальца. это же тестовое приложение... на котором мы стараемся просто сэмулировать разные ситуации на проектах. Допустим у нас ситуация - что было много багов с этими каентарами... и нам таки нужно это экзостив тестинг... вот мы его и делаем :) Ты уж извини что не во всех описаниях заданий прописаны все такие нюансы :) Жизнь сложна... У меня на все времени не хватает.
                    Да и курс этот уже закрыт. Скоро доделаю новый. Там скорее всего будут слегка другие домашки.

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

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

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

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

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

                    то что ты там себе представляешь не соответствует действительности. Залезь в код и посмотри;)

                ты считаешь что профит от такой проверки стоит риска?

                    я считаю что риска нет) Риск точно такой как риск от того что урл может поменятся... Ну ок, слегка больше, но все равно, он намного меньше чем то что реально мы пропустим баги по этому каунтеру для разных ситуаций с действиями... Потому что еще раз - каунтер - это 7 разных каунтеров по сути для каждого действия.
========================================================================================================================
мне кстати не совсем нравиться твоя идея называть "пакет куда ты складываешь полезняшки" как api...
оно просто конфузит слегка... к чему АПИ? :)

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

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

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

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

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

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

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

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


        >>>>>>>>>> у тебя есть скриншотик с "красивым" по твоему устройством проекта? я не совсем понял как выглядит сорс
                мавен-проекта, в котором есть несколько тестовых проектов (как у меня todomvc and google)

                >>>>> не знаю есть ли но вот например:
                common          < это коммон для всех
                gmail/commmon   < а это коммон именно для жмейла
                gmail/model
                gmail/model/pageobjects
                gmail/model/Application.java
                todomvc/сommon  < а это именно для тудуемвиси
                todomvc/...

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

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

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

                 >>>>  ну раз так то и славно... главное что бы ты понимал этот прикол "с недетерминированостью"

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

                 можно сделать переменную Configuration.long_timeout = Configuration.timeout * 3;

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

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

                    >>>>  да не нравится с умножением, заверни во что то - но заверни в метод а не переменную...
========================================================================================================================

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

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

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

                ну такое... может сдесь это и не сильно актуально, смотри сам...


    @Step
    public Emails emails() {
        return Emails.all();
    }

    @Step
    public Emails unreadedEmails() {
        return Emails.unreaded();
    }

    @Step
    public Emails readedEmails() {
        return Emails.readed();
    }

все ок, но просто как идея еще одного варианта апи:

просто

    @Step
    public Emails emails() {
        return new Emails();
    }

но потом можно:

emails().unreaded()
emails().readed()

ну эт такое... я еще сам не уверен что так было бы лучше.... нужно пробовать...


        >>>>>>>> немножк переписал, вроде бы погибче стало...поля стало 2 вместо одного, зато читать проще :)
========================================================================================================================
public class LoginPage {

    @Step
    public void ensureLoggedAs(String email, String password) {
        $("#Email").setValue(email).pressEnter();
        $("#Passwd").setValue(password).pressEnter();
        $(".cmsg").waitUntil(hidden, 15_000);
    }

}

поднимая снова тему о "эншурности"

я бы тут убрал еншуре вместе с вейтом...

а еншуре версию метода встроил бы таки в Application

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

у тебя кстати этой проверку тут и нет:

    public void ensureLoggedAs(String email, String password) {
        new LoginPage().ensureLoggedAs(email, password);
    }


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


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

                поэтому я в тесте открываю open("/"), если есть mail.google.com - значит я где то уже залогинен, и
                перехожу просто в inbox, если нет в урле этого, то начинаю тайпать логин и пароль, в надежде что я
                на accounts.google :)

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

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

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