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

            ?

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


    >>>>>>>> смотри, я переделал, опять) подумал про твою идею 'topics', но т.к. я все еще не умею мапить коллекцию в
            коллекцию, создал отдельные переменные...

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

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


***
                .shouldHave(sizeGreaterThanOrEqual(1))
                .first();

шулд лишний
селениде автоматом подождет именно такого же кондишена

***
    @Step
    public Emails unreaded() {
        return new Emails("zE");
    }

не сильно читабельно получилось...
я бы лучше завернул этот конструктор в другой класс
типа
new UnreadedEmails()

либо так... либо лучше как у тебя раньше было :)

***
.shouldHaveSize(number + 1).get(number));

и здесь шулд лишний

***
container().shouldBe(visible).findAll("tr");

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

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

да, норм, абсолютно достаточно этого пока...

>>> я все еще не умею мапить коллекцию в
            коллекцию,

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

и можно все это реализовать максимум на уровне:

    topic(int index) {

        return new Topic(this.mails.get(index))
    }

а shouldHaveTopics оставить на уровне Emails

***
    public Emails() {
        mailsContainer = container().shouldBe(visible).findAll("tr");
        authors = container().shouldBe(visible).findAll(".yX .yW>span");
        topics = container().shouldBe(visible).findAll(".y6 span[id*=':']");
        messages = container().shouldBe(visible).findAll(".y6 .y2");
    }

    public Emails(String cssClass) {
        mailsContainer = container().findAll(String.format("tr.%s", cssClass));
        authors = container().findAll(String.format("tr.%s .yX .yW>span", cssClass));
        topics = container().findAll(String.format("tr.%s .y6 span[id*=':']", cssClass));
        messages = container().findAll(String.format("tr.%s .y6 .y2", cssClass));
    }

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


Но, почему не переиспользовать уже конструктор с cssClass?

ты же можешь внутри одного другой конструктор вызвать через this(нужныйЦссКласс)

tr.%s

вот эта часть повторяется часто... может она тоже часть какого то "контейнера" который можно вынести повыше?

а может только tr

в общем мне твои локаторы кажутся какими то сильно большими :) но я не уверен что можно упростить
это так - идея обратить на это внимание
***
    private SelenideElement container() {
        return $$(".UI")
                .filterBy(visible)
                .shouldHave(sizeGreaterThanOrEqual(1))
                .first();
    }

там наверное лучше такой локатор будет: $("[role='main']");
но нужно смотреть ближе
***

по лейзи...
в твоей реализации контейнера - мне кажется не важно был бы он методом или переменной
в селениде и так все лейзи...

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


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

                    такие вопросы:
                    - если например багов 10, а тестов упало 9, а не 10, как ты узнаешь, что произошла ошибка? ты где то
                        явно указываешь сколько должно падать?
                    - если ты таки явно указываешь, то зачем тест который всегда падает, достаточно же считать грубо
                        говоря количество фейлов, и если ты скажешь что их должно быть 0, то и ладно...

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

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

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

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

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


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

                 посмотрел на гитхабе, особо ниче не понял, я вообще в js не особо :)

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

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

                 ну а так то - учи джеес)
                 это на самом деле важно для автоматизации также... вот хотя бы что бы знать слегка такие нюансы...
========================================================================================================================