Насильно предлагают отказаться от пейджобжъект, констант и т.д.

Здравствуйте. Насильно предлагают отказаться от пейджобжъект.
Говорят юзать в тесте такие конструкции:

public void test(){
     Navigation navigation = new Navigation();
     navigation.activateSubsystem("Управление НФА");
     navigation.activateTab("Формуляры");
     navigation.expandNode("Формуляры");
     navigation.expandNode("Поступление НФА");
     navigation.selectNode("Приходный ордер на приемку материальных ценностей (нефинансовых активов) (ф.0504207)");
     scroller.getButton("Открыть документ на редактирование");
     scroller.getInput("Номер документа").sendKeys("1111111");
     scroller.getButton("Сохранить документ");
     docBrowser.filter(new String[][]{
        {"Номер документа", "32"},
        {"Поставщик", "Кроп"}});
}

Получается много стрингов в тестах… но так типа наглядней и понятней будет для новичков
Все что я делал до этого, коту под хвост.
ЧТо скажете?

Вопрос то в чем стоит? Ну предложите им cucuber или robot, там вообще домохозяйки писать могут на DSL

а если насильно предлагают, разве есть способ что-то или как-то изменить? :slight_smile:

они не примут никакой кукумбер и т.п.

не хотят вообще задействовать приактики распространенные.

просто свой велосипедик по получению элементов

вот так должен выглядит код диалогового окна по их мнению:

public class HighlightedWindow extends Element {

    public HighlightedWindow() {
        super("//div[contains(@class,'z-window-highlighted')][last()]");
    }

    public void pressTextButton(String buttonText) throws InterruptedException {
        Button button = addChild(Button.getTextButton(buttonText));
        button.click();
        Thread.sleep(1000);
    }
}

и в тестах юзать это так:

highlightedWindow.pressTextButton("Ok").click();
highlightedWindow.pressTextButton("оk").click();
highlightedWindow.pressTextButton("OK").click();

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

@Block(@FindBy(xpath = "//div[contains(@class,'window')]"))
public class DialogWindow extends BaseHtmlElement{

    @FindBy(xpath = "//button[contains(., 'Ok') or contains(.,'OK') or contains(.,'ОК')]")
    public Button buttonOk;
    @FindBy(xpath = "//button[. = 'Сохранить']")
    public Button buttonSave;
}

когда я знаю, что ща появится диалоговое окно я просто делаю так

dialogWindow.buttonOk.click();

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

Вы разкать о горе пришли? Ну…я думаю все Вам сочувствуют, повторюсь - в чем ваша проблема - где постановка вопроса?)

))
ну можно и так сказать

просто вопрос, как быть дальше?)

Браться за код и рыдать.
Когда компания начинает насильственно определятт рамки твоего влияния, нужно или менять что то или увольняться. Мне проще было быть на собеседованиях, и смотреть кого приглашают, потому что новичек, через месяц уже не должен быть новичком в компании, а если кто то хочет сэкономить на специалистах…ну, тогда пусть кому то заплатят больше…или вовсе другие.

1 лайк

ладно, закрываем тему

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

Все же “насильно заставляют” - это не говорят “делай так”, как я понял, а говорят - “так должно быть”. То есть есть место для диалога, обсудить, понять, обьяснить, разобраться, почему так должно быть и должно ли так быть…

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

сегодня обсуждали и все показывал и рассказывал )

Понимают, что это правильно, но для того, чтобы кто-то разобрался в том, что я написал, типа требуется время.
А так будет проще вкурить всем.

мне оказалось не проще понять их тест :slight_smile:

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

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

2 лайка

таки да :slight_smile: тут не поспоришь…

Треш на самом то деле!

Что вот это значит?

navigation.activateSubsystem("Управление НФА");

нажать на кнопку “Управление НФА”? Типо перейти, так как стоит navigation, или это значит, что одна строка и кликает и еще что-то делает. И все это в одном флаконе - активировать “Управление НФА” в системе?

что такое скроллер? Получить кнопку “Открыть документ на редактирование”. Получил, а дальше я что с ней сделал? Или get - это кликнуть по кнопке со стрингом внутри?

scroller.getButton("Открыть документ на редактирование");

хм… Сложновасто как-то, сложно представить, как сложные вещи там будут написаны…

navigation.activateSubsystem("Управление НФА");
это значит - раскрыть слой в меню (ракроются конечные пункты)

  • пункт1
  • пункт2
  • пункт3
  • пункт4
  • пункт5 (раксрыт)
    - конечный узел 1
    - конечный узел 2
    - конечный узел 3

scroller.getButton("Открыть документ на редактирование");

тут я приврал, выглядит так:

doc.toolbarPressButton("Открыть документ на редактирование");

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

Я мог бы с ходу привести с 10-ток причин, почему это можно назвать говнокодом плохим тестом. Но вы наверное итак о них знаете.

Нужно отстаивать свою позицию. Но аргументы следует приводить не только технические. На одном тесте невозможно понять весь масштаб потенциальной трагедии. :slight_smile: А еще лучше не учить идиотов жизни, а провести живой эксперимент: взять 2 мануальщика и посмотреть, сколько времени у них уйдет на освоение 2х предложенных подходов (каждому свой). Причем, не просто на осознание того, как писать тесты, а и оценку времени, потраченного на issues root cause analysis и потенциальный фикс / репортинг.

П.С. Или может я неправильно понял, о каких новичках идет речь? :slight_smile: Потому что если речь идет о пусть даже любом java-ориентированном студенте - под хорошим менторством он через месяц будет понимать даже самый сложный (с точки зрения языковых конструкций) код. Так что для кого затеян этот фарс, кроме как для мануальщиков, я не могу себе представить.

3 лайка

И как же это все то понять, без наводки и 100 грамм.

Вот @ArtOfLife, хорошо все подметил… :slight_smile:

Покажите им переписку, руководству, хотя наверное может и не стоит, лучше провести тест с фокус группой из автоматизаторов, как описали выше. Кста правильно сделали, что написали. Это хороший жизненый пример для людей, которые когда-то столкнуться с подобной ситуацией и будут тупить в ее разруливании… :slight_smile:

1 лайк

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

тогда им трындец как сложно будет и будут учится сложным и непонятным и неправильным вещам :slight_smile: А когда будут спрашивать на подобных ресурсах, люди будут в небольшом шоке :slight_smile:

Я бы предложил аргументировать так:
При использовании best practices стоимость maintenance будет <посчитай для своих тестов, основываясь на показателе количества проапдейченных упавших тестов за 4 часа, к примеру>
Из минусов: новичку на проекте требуется некоторое время, чтобы вкурить то, что уже есть. Сколько - посчитай сам, основываясь на статистике в проекте.
При использовании того варианта, что там предложен, стоимость maintenance возрастёт. Насколько - посчитай. Прикинь кол-во тестов, прикинь кол-во общих элементов для нескольких тестов и представь ситуацию, что группа локаторов поменялась, например. Я прогнозирую в 3…5 раз. Прикинь, сколько ты часов в неделю занимаешься maintenance и умножь полученное значение на этот коэффициент. Затем посчитай, когда использование best practices начнёт давать профит. Сделай графики для расхода времени с использованием BP и без. Всё это предоставь заказчику и предложи ему выбрать, хочет ли он терять немного времени сначала или дофига времени потом.
Кстати, если автотестов у вас в проекте немного и апдейтятся они нечасто - может быть, его решение имеет смысл, ибо срок окупаемости BP будет много выше, чем срок жизни автотестов в проекте.

2 лайка