Архитектура приложения влияет на архитектуру тестов? Шта?

А что не так?

если это TDD то наоборот)

BDD, ты хотела сказать? )

Да потому что тесты по определению не зависят от имплементации проекта

если это TDD то наоборот)

Нет.

Да потому что тесты по определению не зависят от имплементации проекта

По какому определению?

Его можно хоть на другом языке переписать, хоть с ООП на функциональный, хоть на брейнфаке - тесты проверяют аутпут.

мне кажется это зависит от Уровня написания тестов: на "черный ящик" мы их пишем или на "прозрачный"

По какому определению?

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

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

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

интересно, но пожалуй все зависит от подхода, тестирование на уровне кода или тестирование пользовательского интерфейса.

У вас есть сеть из 30 микросервисов или один монолит, вы считаете что это не будет влиять на архитектуру тестов?

Если да, то сориян, проблема снова в вас.

Если да, то сориян, проблема снова в вас.

Проблема в том то ты пишешь эвфемизмы. В микросервисах PageObject - он где?

Проблема в том то ты пишешь эвфемизмы. В микросервисах PageObject - он где?

Скопетаню, конечно, но в тестах. ;[

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

Когда мы говорим про PageObject там вообще может фронтенда не быть.

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

Если там отдается json то ровно то же самое.

Если там отдается json то ровно то же самое.

JSON чего, простите?

Вы страницы jsonами отдаете?

Микросервисы отдают исключительно страницы?

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

А если у вас с реакта переписали на ангуляр, то вы тесты тоже переписываете?

> Когда мы говорим про PageObject - тест получает html страницу

А если у вас с реакта переписали на ангуляр, то вы тесты тоже переписываете?

Если меняется логика - то да.

А если не меняется логика?

А если не меняется логика?

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

придется переписывать

Если не меняется логика то вы, вероятнее всего, ничего не переписали.

Если меняется бизнес-логика -> переписываются тесты. Если меняется логика взаимодействия с сервисом -> переписываются page objectы. Если меняются локаторы -> переписывается мап локаторов.

Всё просто и логично.

Если не меняется логика то вы, вероятнее всего, ничего не переписали.

Very sad for you. Можно полностью переписать все приложение, ускорив производительность, но ни капли не поменяв логику. И тесты проверят что рефакторинг прошел корректно. В этом их и смысл.

Это называется в программировании интерфейс, или, по-другому - "контракт".

> Very sad for you.

Скорее for you, если под логикой вы понимаете только бизнес логику.

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

Рефакторинг производительности -> тоже изменение логики приложения, сориян.

похоже на паттерн разработки тестов PageObject

да. Оно и есть. Мне не нравиться что в месте которое называется @Test есть строки типа cat = new cat или написано cat.run вместо run Сколько примеров в инете не смотрел везде есть что то лишнее в том блоке который называется @Test

Рефакторинг производительности -> тоже изменение логики приложения, сориян.

Я этот перл сейчас даже коллегам покажу.

Я этот перл сейчас даже коллегам покажу.

Ни в чем себе не отказывайте, можете даже стикер на монитор повесить, что бы не забыть.

чет вы злые сегодня )

Рефакторинг производительности -> тоже изменение логики приложения, сориян.

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

рефакторингом можно назвать все то, что из 3rd party (а еще лучше - стд либа) было поменяно и ты переписал код на "получше" - заодно, например, убрав deprecated ворнинги

А если добавить индекс на таблицы в базу, то это тоже изменение логики, ага.

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

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

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

А если добавить индекс на таблицы в базу, то это тоже изменение логики, ага.

в SQL проектах это целая бизнес задача, которая аффектит дохрена чего, если что

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

=)

в SQL проектах это целая бизнес задача, которая аффектит дохрена чего, если что

уловка 22 да ? подходит?

не очень

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

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

Ну, а тесты то, которые при этом проверяют селекторы в сгенеренной странице, будут переписываться или нет?

эти тесты - не будут :)

да. Оно и есть. Мне не нравиться что в месте которое называется @Test есть строки типа cat = new cat или написано cat.run вместо run Сколько примеров в инете не смотрел везде есть что то лишнее в том блоке который называется @Test

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

эти тесты - не будут :)

а если поменялся способ генерации страниц ?

или же при изменения фреймворка, автомейшн перестанет видеть какой-то селектор ?

или же при изменения фреймворка, автомейшн перестанет видеть какой-то селектор ?

то значит это вам ответ того, как правильно разработчики "рефакторят"

цели рефакторинга - не сделать "быстрее". Цели рефакторинга - сделать поддерживаемее.

цель рефакторинга определяет заказчик рефакторинга.

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

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

это например.

Вы путаете терминологию

Читаем Фаулера

ERROR: S client not available

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

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

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

из определения: ни UI, ни Unit тесты не должны будут изменится в результате рефакторинга - и логика не должна быть затронута... но это из определения в идеальном мире...

и "остальное" - получается то же должно остаться не изменным

и "остальное" - получается то же должно остаться не изменным

все так. Именно поэтому я несколько раз уточнил, что в реальном мире "малый" рефакторинг - это переписывание 3rd party либ и языковых stdlib или еще уже - тупо конструкторы типов данных

вывод: рефакторинга с бизнесс смыслом не бывает

есть и другой рефакторинг - когда ты переписав а ничего с точки зрения business value не добавив - сделал код понятнее, поменял вызовы, или доказал и проверил, что можно обойтись без лишнего вызова процедуры. Тесты показали, что твой рефакторинг не сломал business value = профит.

Привет. На каком языке или какой фреймворк юзать чтобы тест начинал выглядеть вот так: @Test registration (login.password) buy product1 assert (text,"Спасибо за покупку") К слову юзаю яву. Не нравится что нужно объявлять переменные в тесте или через точку ссылатся на какой то элемент. Стремно выглядит(( SignUpPage signUpPage = new SignUpPage(driver); signUpPage.isInitialized(); Я новичок, Сильно не бейте =)

Selenide, конечно!

Употреблять термин "рефакторинг", как что-то, что заставляет измениться бизнес логику, или тесты, или его заказывает бизнес-работник - не нужно.

Это все запутывает и взрывает моск.

Далее, если мы обмазались TDD подходом и сначала написали тесты, а приложения еще нету, то архитектура приложения ну никак не может повлиять на архитектуру тестов, ведь ее не существует!

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

спасибо посмотрю. А вообще да мне хочется чтобы тесты были максимально читабельными. а все что глубже пусть обрастает своей логикой реализации. норм. хотя может используя тот же Page object делать как есть а сверху надстраивать еще что то. типо bdd cucumber кажется там удобочитаемость приятной становиться

вывод: рефакторинга с бизнесс смыслом не бывает

Это если product owner некомпетентный. Потому что без рефакторинга все тонет в говнокоде и костылях Плавали, знаем, жуткое и жалкое зрелище

Далее, если мы обмазались TDD подходом и сначала написали тесты, а приложения еще нету, то архитектура приложения ну никак не может повлиять на архитектуру тестов, ведь ее не существует!

При ванильном TDD такого быть не может, чтобы тесты были готовы а приложении нет :)

TDD это написание приложения, с помощью написания тестов.

Это если product owner некомпетентный. Потому что без рефакторинга все тонет в говнокоде и костылях Плавали, знаем, жуткое и жалкое зрелище

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

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

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

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

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

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

это как, прости? :)

незнаю кто такой этот Фаулера, но видимо придеться почитать

https://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D1%83%D0%BB%D0%B5%D1%80,_%D0%9C%D0%B0%D1%80%D1%82%D0%B8%D0%BD

это как, прости? :)

Ну так, вписываешь в тесты что посылая запрос на /abc ты ожидаешь по таким-то селекторам увидеть значения x,y,z.

А потом все это прогеры уже закодивают.

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

в кровавом водопаде, где есть утвержденный дизайн "кнопка с id=X" с легкостью. Только в реальности я про такое не слышал

https://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D1%83%D0%BB%D0%B5%D1%80,_%D0%9C%D0%B0%D1%80%D1%82%D0%B8%D0%BD

когда ты сказал всем читать ты какой менно его труд имел ввиду ?

Ну так, вписываешь в тесты что посылая запрос на /abc ты ожидаешь по таким-то селекторам увидеть значения x,y,z.

звучит как кровавый ынтырпрайз

"Рефакторинг" =)

у тебя селекторы продуманы изначально?))

у Фаулера можно читать всё - чувак пишет хорошие вещи

в кровавом водопаде, где есть утвержденный дизайн "кнопка с id=X" с легкостью. Только в реальности я про такое не слышал

Ну так речь же о том чтобы стремиться к этому. Со временем и приходом опыта этот скилл возрастает. Частично можно реализовать тесты уже до того как прогеры выкатили первую версию.

у тебя селекторы продуманы изначально?))

Ну так верстальщик классы то у себя вписал.

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