Если говорить об архитектуре, то, думаю, важно еще подчеркнуть необходимость вытаскивания из PageObject жирной логики в классы степов или хелперов (будь они не ладны), а проверки в классы ассертов.
Т.е. ну держать элемент и атомарную обертку над этим элементом - это ок. Но как только над элементом или группой элементов будет производиться набор действий согласно бизнес логике, такие классы начинают слишком жирно разрастаться. Оглянуться не успеешь, как у тебя уже 1000+ строк в файле.
А рефачить будет больно. Лучше сразу разделять по семантике, по началу будет казаться, что это не выгодно, но на долгой дистанции очень удобно
Я всё таки приверженец того, чтобы на первом уровне тесты читались как можно более понятно и старались содержать Arrange-Act-Assert на видимом уровне, даже, если это противоречит принципу DRY; а также, чтобы названия методов были полностью однозначны.
Например, тест, состоящий из одной строки сам по себе не очень информативный, и когда в репозиторий автотестов коммитят больше 5 человек это может сыграть злую шутку.
deftest_main_page(): MainPage.verify_page()
Я бы вытащил сюда явное открытие страницы и verify_page заменил бы на VerifyHeaderAndNews. А лучше бы разбил на два метода, или даже на два теста. Ибо если отвалится хэдер, но будет лента - мы об этом узнаем не сразу.
Еще, кстати, вопрос, почему внутри одного проекта выбраны различные нотации именования? для классов CamelCase, а для имен файлов и методов snake_case?
Обожаю частицы и работу с ними, стараюсь максимально их использовать, интересная статья, особенно радует визуализация параметров.
Но огромный жирный минус за текстуры, буквально 30 секунд в фотошопе и можно сделать огонь с заявкой на реализм. Думаю, все же стоит довести до конца, чтобы был совсем вау эффект. Могу даже поделиться текстурками
Вопрос знатокам, на levels.fyi зарплата указана до вычета налогов? Если да, то налоги применяются ко всей сумме или только то, что реально получил? Типа стоки не облагаются, пока не обналичены?
А можно как-то найти ссылки на все иллюстрации? Вот мне не повезло, я купил книгу довольно рано, и где-то есть qr, а где-то нет. Например тот же рис 1.11
Добавлю два популярных метода, которых не увидел тут:
1. Внутриигровая подписка: допустим есть айтем, который стоит 10 у.е., но ты можешь продать подписку за 1 у.е. с учетом того, что надо в течение 10 дней подряд заходить и собирать купоны.
2. Реклама on-demand: все просто, в игре всегда есть кнопка просмотра рекламы, за которую тебе заплатят внутриигровую валюту
А чем вам не понравился базовый функционал скелетной анимации unity? Берете тот же атлас, соединяете части в один объект и в аниматоре пользуете translation и прочие прелести. Есть неплохой видос с unite 2014, как это делается без лишних движений.
Это все, конечно, прекрасно, но пользователей, которые отдают отчет своим действиям меньше 1/5.
Статья оригинала больше похожа на вброс, ибо, во-первых, даже на скрине видно, что уязвимости пофикшены, и во-вторых, с тем же успехом на том сайте можно найти огромные уязвимости как всеми нелюбимой ОС, так и браузера топик ориджина.
А как же директ реклама, которая время от времени может привести на фишинг? Особенно юзверя, который так рьяно искал нужный ему товар, а тут хоп скидос только сегодня 20%, надо только нажать «Принять» в регистрационной форме.
Если говорить об архитектуре, то, думаю, важно еще подчеркнуть необходимость вытаскивания из PageObject жирной логики в классы степов или хелперов (будь они не ладны), а проверки в классы ассертов.
Т.е. ну держать элемент и атомарную обертку над этим элементом - это ок.
Но как только над элементом или группой элементов будет производиться набор действий согласно бизнес логике, такие классы начинают слишком жирно разрастаться. Оглянуться не успеешь, как у тебя уже 1000+ строк в файле.
А рефачить будет больно. Лучше сразу разделять по семантике, по началу будет казаться, что это не выгодно, но на долгой дистанции очень удобно
Какой ужасный гайдлайн у этого вашего пайтона. Но ок, вопрос закрыт, спасибо =)
Я всё таки приверженец того, чтобы на первом уровне тесты читались как можно более понятно и старались содержать Arrange-Act-Assert на видимом уровне, даже, если это противоречит принципу DRY; а также, чтобы названия методов были полностью однозначны.
Например, тест, состоящий из одной строки сам по себе не очень информативный, и когда в репозиторий автотестов коммитят больше 5 человек это может сыграть злую шутку.
def test_main_page():
MainPage.verify_page()
Я бы вытащил сюда явное открытие страницы и verify_page заменил бы на VerifyHeaderAndNews. А лучше бы разбил на два метода, или даже на два теста. Ибо если отвалится хэдер, но будет лента - мы об этом узнаем не сразу.
Еще, кстати, вопрос, почему внутри одного проекта выбраны различные нотации именования? для классов CamelCase, а для имен файлов и методов snake_case?
Но огромный жирный минус за текстуры, буквально 30 секунд в фотошопе и можно сделать огонь с заявкой на реализм. Думаю, все же стоит довести до конца, чтобы был совсем вау эффект. Могу даже поделиться текстурками
Вопрос знатокам, на levels.fyi зарплата указана до вычета налогов? Если да, то налоги применяются ко всей сумме или только то, что реально получил? Типа стоки не облагаются, пока не обналичены?
1. Внутриигровая подписка: допустим есть айтем, который стоит 10 у.е., но ты можешь продать подписку за 1 у.е. с учетом того, что надо в течение 10 дней подряд заходить и собирать купоны.
2. Реклама on-demand: все просто, в игре всегда есть кнопка просмотра рекламы, за которую тебе заплатят внутриигровую валюту
Статья оригинала больше похожа на вброс, ибо, во-первых, даже на скрине видно, что уязвимости пофикшены, и во-вторых, с тем же успехом на том сайте можно найти огромные уязвимости как всеми нелюбимой ОС, так и браузера топик ориджина.