Знаешь термин чайка-менеджмент?

это похоже на helicopter parents ?

прилететь, наорать, нагадить и улететь.

хаха расскажу коллегам

а я так и не понял что ему нужно было -_-

хотя мб оно и к лучшему

он и сам не знал.

а я так и не понял что ему нужно было -_-

чувак не мог приложеньку правильно запустить, но уперто считал что какой-то результат там есть

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

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

Кто из нас всех более лучше прав? Я так думал что acceptance тесты проверяют действия в системе в целом, без разбития на атомарные действия.

Да и лазить в базу смотреть что там появилось - как-то не по приемочному. С другой стороны замечание о разбитии на 2 теста довольно технично.

а что мешает вписать просто в expected result что после такого-то степа когда вносят поля то они правильно обработаются

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

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

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

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

Погоди.

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

в таком случае разбивать 100%

Какую проблему мыы решаем? То что тест надо разбить или то что он в базу ходит?

Какую проблему мыы решаем? То что тест надо разбить или то что он в базу ходит?

Мы решаем проблему качественной архитектуры тестов в целом. Если тест состоит из нескольких сложных составных действий, то это не выглядит очень хорошим. Если тест проверяет с помощью залезания в базу - тоже не очень хорошо. Вопрос, что здесь является меньшим злом и есть ли может какие способы и рыбку съесть, и acceptance зачесть.

Надо разбивать

> Если тест состоит из нескольких сложных составных действий, то это не выглядит очень хорошим Чёйта?

Не по феншую?

Да не так уж и много там действий похоже.

> Если тест состоит из нескольких сложных составных действий, то это не выглядит очень хорошим Чёйта?

Ну ежели эти сложные действия сами по себе не проверяются отдеьно

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

Ну ежели эти сложные действия сами по себе не проверяются отдеьно

Это нормальная ситуация независимо от того, проверяются ли составные действия или нет.

Это нормальная ситуация независимо от того, проверяются ли составные действия или нет.

Только тогда отвечать за них нельзя

Можно и нужно.

Нужно просто нормальный fail reason пробрасывать.

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

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

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

Как говорится: Жить спокойно - не спорить )

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

О боже, тест падает при изменении архитектуры приложения. Жуть-то какая.

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

А если у тебя ui в базу пишет говно какое-то, как ты это контролировать будешь?

Да, неприятно.

Сам функционал записи в базу кстати можно в юнит-тесты добавить разрабу.

Не не не мы говорим именно при _приемочные_

юниты это совсем другое

А если у тебя ui в базу пишет говно какое-то, как ты это контролировать будешь?

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

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

а если это оплата кредиткой он в базу не лезит не смотрит ничего ? =)

Это разные классификации, от сложности не зависят.

Тёплое с мягким.

Ммм... А не проще понабирать из базовых сьют по 5-10 самых простых тестов? Будет надёжнее, хоть какая-то гарантия что ничего не сломали.

а если это оплата кредиткой он в базу не лезит не смотрит ничего ? =)

Тогда как он узнает что система правильно отработала?

Тогда как он узнает что система правильно отработала?

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

Должна.

Тогда как он узнает что система правильно отработала?

полезет в базу и посмотрит что транзакция создалась и это все в рамках того же тест кейса

И это все равно можно называть приемочным тестированием? Тут попахивает функционаьным :)

И это все равно можно называть приемочным тестированием? Тут попахивает функционаьным :)

Павел, вы приемку с черным ящиком не путаете? я про понятия...

Возможно путаю

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

а приемка не на черном ящике проводится?

как это вообще связано?

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

В свете этого лезть во внутренности системы видится нарушением контракта.

Шта

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

Ну возможно я загоняюсь и это уже овер требования

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

Согласен, в каком то смысле и юнит можно назвать приемкой. интерфейс класса это заказчик, а сам класс это реализация.

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

Ладно, сиим постановим следующее: 1) Большой жирный тест разделить на два простых. 2) Разрешить тесту невозбранно лезть в самую базу, дабы убедиться что все прошло канонично.

ERROR: S client not available

Попробуйте так. А потом поделитесь с нами своей болью ретроспективно)))

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

Ну возможно я загоняюсь и это уже овер требования

Студент мышкой протыкал и если страшного не заметил - в продакшн клиенту.. ну так себе контроль качества :) Немного ненадёжно. Или у вас ci и на деплое что-то уже гоняется?

Попробуйте так. А потом поделитесь с нами своей болью ретроспективно)))

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

Студент мышкой протыкал и если страшного не заметил - в продакшн клиенту.. ну так себе контроль качества :) Немного ненадёжно. Или у вас ci и на деплое что-то уже гоняется?

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

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

апи и всякое внутреннее у нас покрыто юнитами и функциональными неплохо.

А вот как мы начали велосипедить rich интерфейсы на JS, добавилась еще боль верстки и рендеринга всяких форм.

у всех эта боль с гуем, я думаю. панацею пока не встречал

> Если тест состоит из нескольких сложных составных действий, то это не выглядит очень хорошим Чёйта?

какая-то бюрократия

какая-то бюрократия

что именно?

какая-то бюрократия

атомарность

Всё, прочитал ветку. Бюрократия решать как называть тесты/ разбивать, не разбивать, солить или перчить. Вроде же должно двум простым правилам следовать. Решать проблемы и быть готовым к переделке/подыханию.

а подскажите ж отличный скриншоттер для мака. Можно платный. Skitch задолбал уже глючить :(

а подскажите ж отличный скриншоттер для мака. Можно платный. Skitch задолбал уже глючить :(

яндекс диском пользуюсь.

а подскажите ж отличный скриншоттер для мака. Можно платный. Skitch задолбал уже глючить :(

стандартные cmd+shift+4 не нравится?)

яндекс диском пользуюсь.

но мне полезно сразу паблик ссылкой в буфер.

стандартные cmd+shift+4 не нравится?)

а стрелочки-палочки-галочки?

это уже не скриншоттер

https://app.prntscr.com/en/faq.html

это уже пейнт для скриншотов

Мне нужно и паблик ссылкой, и в буффер обмена и с редактированием, и с историей, и все сразу.

Мне нужно и паблик ссылкой, и в буффер обмена и с редактированием, и с историей, и все сразу.

вот ядиск это делает всё, в полтора клика.

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

https://app.prntscr.com/en/faq.html

lightshot норм тема

https://www.techsmith.com/jing.html

а подскажите ж отличный скриншоттер для мака. Можно платный. Skitch задолбал уже глючить :(

Greenshot

jing, joxi

Monosnap рекомендовали уже?

gyazo / я скриншот есть еще приблуды сразу_в_слак, типа marker и тд