Интересно узнать ваше мнение. Используете ли вы тесты при написании кода, если да, то каким именно образом, и в каком порядке, используете ли подход TDD, расскажите и плюсах и минусах данного подхода. Что считаете важным в покрытии тестами, только «узкие» места, или покрытие всего чего можно.
Написание хороших тестов может занимать столько же, а то и в разы больше времени написания кода. А теперь попробуйте это продать клиенту. В нашей суровой реальности — тесты это непозволительная роскошь)) Тесты пишут обычно в продуктовых компаниях, но в большинстве случаев из-за жестких дедлайнов, это тесты ради тестов, которые покрывают совсем тривиальные кейсы. И после выхода в прод, оно все равно падает, хотя тесты все зеленые)
Люблю писать юнит тесты, обычно покрываю до ~100%, ненавижу писать интеграционные тесты, ттд не юзаю, нет никакого смысла писать тест вперед кода, при соблюдении небольшого свода правил можно полностью отказаться от мануальных тестеров, но чаще тесты не хотят, а тестеров хотят
Тесты пишу, код в основном пишучерез ТДД. Если делаю прототип — тесты как правило не нужны. Главное чтобы прототип в продакшен не пошел =) Пишем тесты на базу данных, энд-ту-энд Селениум тесты, юнит тесты. Тестировщиков у нас нет, как и у многих других компаний в Швеции.
Менеджеров про тесты спрашивать не надо, надо просто их писать. Но чтобы их писать — нужно сначала вложиться в инфраструктуру, например настроить билд сервер чтобы тесты прогонял. Или подготовить докер контейнер с тестовой базой...
Буквально вчера написал в паре с коллегой 14 тестов на класс который работает с базой данных и поймал баг. Когда пишешь тесты и ловишь баги — мотивирует писать их дальше. в 2008 работал в компании где был продукт с 250 000 тестов (привет CargoWise!)
Когда пишешь тесты и ловишь баги — мотивирует писать их дальше.
Тоже неоднократно ловил себя на этой мысли.
Но лучше просто баги не писать, конечно так и для бизнеса дешевле и разработчику спокойнее.
Пишем и пишу.
ТДД смотря как его рассматривать. Если по букве то нет, не соблюдаем. Нет смысла писать тест на какуюто крупную фичу, если еще не совсем ясен интерфейс ее работы. А если обнаружен баг, то первым делом нужно написать тест, который воспроизведет баг и упадет.
На проекте около 3к тестов. 99% из них — интеграционные, без моков/стабов.
Не представляю себе жизни без тестов. Ну точнее представляю, но ябал я такую жизнь.
Кстати заметил, что чаще всего баги проскалзывают в тех местах где тесты более всего лень писать. Например где-то ожидаеться отсутсвтвие какого либо параметра (null), и нужно покрыть кейс когда параметр null, но обчно вдохновения хвататет только на покрытие только основных сценариев, а написать еще один тест с null очень лень), но нужно себя заставлять
Совсем недавно для себя открыл то как индусы юнит тесты пишут. Моканые на замоканые помоканые чисто верхние условия. Ни реальный интегрейшн не тестеруеться, ни реальная функциональность, чисто на отъе***сь. Зато код кавередж ахренеть высокий. А то что у них это все в продакшене навернеться к черту на любой чих, и делает вообще не то что нужно, так это уже не их проблемы.
Любопытно, много ли тут таких топящих за то как важны тесты ?
50%. А еще 49.99% имеют задачи вида «дано ххх(а,б,с) получить yyy»/
50%. А еще 49.99% имеют задачи вида «дано ххх(а,б,с) получить yyy»/
На моей практике таких задач от силы 10%
Даже ФП, которое любую задачу пытаеться сводить к «дано ххх(а,б,с) получить yyy» не особо помагает.
Или наборот — никаких моков, все лезет на int и там колбасит по полной и базу и сервисы другие, естественно тесты раз на раз то красные то зеленые )))
Хм. Наоборот тесты которые реально колбасят в базу полезная весчь. Вообще хз зачем эта дуристика с моками.
Затем, чтобы запустить, например, три таких теста впараллель и не строить для них три реальных базы.
Непонятно что мешает иметь одну выделенную базу, и запускать тесты последевательно.
Интегрейшн не обязан быть мегабыстрым. И не всегда даже частым.
Непонятно что мешает иметь одну выделенную базу, и запускать тесты последевательно.
Иногда хочется, чтобы тесты проходили не за трое суток, а хотя бы за час.
Интегрейшн не обязан быть мегабыстрым.
«Мегабыстрым» никто не должен быть, потому что «мега» тут эмоциональная характеристика, которая ничего конкретно не означает.
Но он должен быть достаточно быстрым, чтобы работа не замедлялась из-за него.
И не всегда даже частым.
В моих условиях «интегрейшн» в полном составе запускается не реже раза в сутки. И то, временами это оказывается слишком редким.
Иногда хочется, чтобы тесты проходили не за трое суток, а хотя бы за час.
Базу в памяти загоните, + несколько инстансов. Может быть даже быстрее моков, и уж точно легче
Но он должен быть достаточно быстрым, чтобы работа не замедлялась из-за него.
Ставь тесты на коммит или на пул реквест на удаленном серваке. Даже знать не будешь какое у них там время прохлждения
Ставь тесты на коммит или на пул реквест на удаленном серваке
Это пока в тимпе один — два девелопера, если много то можно и не дождаться своей очереди до конца рабочего дня. Было уже такое :-)
Базу в памяти загоните, + несколько инстансов. Может быть даже быстрее моков, и уж точно легче
И пересоздавать на каждом запуске. Нет, не легче и не быстрее.
Ставь тесты на коммит или на пул реквест на удаленном серваке. Даже знать не будешь какое у них там время прохлждения
Буду, Jenkins письмо пишет о результате.
А почему бы не засунуть базу в докер контейнер и запустить хоть сотню параллельно?
Или вообще писать тесты таким образом, чтобы их можно было запускаться параллельно. Пользователи, ведь, как-то умудряются работать с системой одновременно.
Потому, что тест должен быть изолированным. Если одно и то же будут менять несколько тестов то они будут падать.
Вы точно пишите тесты?
Потому, что тест должен быть изолированным
Изолированным от чего? Или у вас каждый тест меняет все записи во всех таблицах/коллекциях?
Вы точно пишите тесты?
Бля буду.
Изолированным от чего? Или у вас каждый тест меняет все записи во всех таблицах/коллекциях?
У нас несколько десятков тысяч тестов, как думаете, есть пересечения?
К примеру, приход денег на счет, списание комиссии, перевод на другой счет, установка/изменение лимитного кредита, автоплатежи. Расскажите, как все тестируется на одной базе одновременно..
У нас несколько десятков тысяч тестов, как думаете, есть пересечения?
Так разделите тесты чтобы то, что пересекается не запускалось параллельно и запускайте параллельно то, что не пересекается.
Расскажите, как все тестируется на одной базе одновременно..
Не все одновременно, а группы тестов с непересекающейся функциональностью параллельно.
И если и пересекается, можно два теста запускать пол разными юзерами/токенами, например. Чаще всего они не меняют данные друг-друга, по крайней мере таких кейсов тоже можно выделить достаточно для параллельного запуска.
Не говоря уже том, что бы поднять разные окружения, как уже говорили, благо есть контейнеры и облака.
Держи вот норм доклад по теме xpdays.com.ua/...ional-tests-really-quick
Как минимум напрашивается вариант различных пространств имен. Например, каждый тест, выполняемый одновременно с другими, взаимодействует с системой под своей учетной записью. Но тут уже возникают вопросы вида: «а сколько таких учеток заводить», «когда и как их заводить», «какую учетную запись использовать в конкретном тесте». Эти проблемы решаются, нужно только учитывать, насколько широкий доступ у нас есть к тестируемой системе. Например, можем ли мы закинуть нужные данные напрямую или будет ли некоторый предопределенный набор данных и насколько часто он обновляется. Подобная тема вполне сгодится для небольшой статьи, для комментария как-то великовато.
Но при работе с живой базой наибольшим недостатком является время выполнения, особенно, если у вас, по вашим словам, десятки тысяч тестов. Тут без заглушек будет трудно. Но при этом:
1) А все ли эти тесты реально направлены на тестирование базы, а не каких-то методов, которые преобразуют данные, переданные структурой? Иными словами, на участке работы того или иного модуля взаимодействие с базой в принципе не происходит, хоть с заглушками, хоть без.
2) А все ли тесты реально нужны именно на живой базе? Часть вполне можно делать с заглушками, но часть (для надежности) — на живой системе.
1. Потому, что база тоже меняется периодически.
2. Потому, что тестируем не базу.
3. Потому, что по базе на тест дорого.
Консистентность данных может быть нарушена, особенно когда тесты выполняются пралельно, на INT могут залить другую версию, левые данные, проверять фичи и прочее прочее.
В тестах должно быть все мегастабильно и одинаково, чтобы падать и меняться могла только тестируемая часть, инче тест непонятно что тестирует — сторонний сервис или базу которую мурыжат все кто не попадя...
Чтобы мурижить базу тесты пишут для базы и они обычно на сиквеле и пишутся, если это сиквел :-)
Первое правило интегрейшн тестов — база не должна шариться :-)
Второй вариант, писать недоинтегрейшн встраиваемой базкой, все эти SQLLite, H2, etc. Не всегда годиться конеш.
TDD коли можна, якщо рефакторінг то обов’язково перед внесенням будь-яких змін. У складних випадках integration тести якщо unit не можна зробити. Для QA завжди додаю таски щоб автоматизували сценарії задокументовані у спеках.
Моя специфика — сетевые сервера разных видов, крайне редко это веб, в основном же что-то другое (были SIP, FIX и не только), протокольные стеки со сложной (и часто громоздкой) логикой.
Любая сколь-нибудь сложная функциональность не принимается без контролирующих её тестов (на этапе ревью). Но: «тесты не для поиска багов, а для написания верифицируемого в контролируемых условиях кода», соответственно, верификация (начиная с простейшей визуальной) — основное средство подтверждения функциональности кода, а тесты работают «подпоркой» для того, что человек в принципе плохо читает в коде.
Все реализуемые юзкейсы прорабатываются и покрываются тестированием. В основном тесты функционально-сценарные, с подключением некоторого подмножества уровней целевого стека и мокания внешних сущностей (сеть, DB, биллинг и тому подобное), могут имитироваться компоненты — внешние участники. Юнит-тестов мало, только на компоненты, логика которых достаточно сложная, но укладывается на одну функцию или метод. На функции-переходники тесты не пишутся, потому что их функционал эффективнее покрывается сценарно.
Тесты проверяются, насколько позволяет инфраструктура, через CI средства типа Jenkins, непрохождение тестов запрещает приём коммита в дерево.
Проверка факта самого тестирования реализуется верификацией теста (как уже сказано, в основном визуальной) и инверсиями. Инверсия — это введение помехи в обстановку или входные воздействия таким образом, чтобы финальное условие теста не выполнялось; чем тоньше ломающее воздействие, тем ценнее конкретная инверсия. Не всем тестам нужна инверсия, но где её удобно ввести, она позволяет выловить особо неожиданные «подводные» нарушения логики. TDD не используем, потому что непригоден (если не заниматься самообманом) для длительного сложного проекта с минимумом тупого кода — посредника. BDD применяется неявно, за счёт создания тестов согласно проверяемым сценариям.
Всё, что можно и достаточно легко рандомизировать при выполнении теста, рандомизируется. Для SIP, например, это идентификаторы звонков и тегов, имена/номера участников, приписанные им IP-адреса и так далее. Пару раз на этом находились странные эффекты :)
Всегда стараюсь покрыть функционал согласно требований.. Но не то, что писали другие или правильность работы библиотек.
Но пишу после написания кода, в силу неопытности и/или лени.
Плюсы лучше почитать у дяди Мартина..
Год назад пришли всей командой к тому, что не принимаем PR без unit-тестов ко всему, не зависимому от платформы (Android в нашем случае), коду. Благо, DI в сочетании с Clean Architecture к этому располагают. Плюс, пишем интеграционные тесты к DAO и миграциям БД. UI-тесты делегировали QA-команде. :) Первые гоняем на CI — сборка, естественно, падает, если какой-то из тестов не проходит.
Ни об одном из этих пунктов не жалеем.
Это очень положительно сказывается на здоровье кодовой базы (и уровне предсказуемости поведения написанного кода), и спустя год при реализации любой бизнес-логики и проектировании архитектуры очередной сложной секции мыслишь через призму вопроса самому себе «а насколько удобно это будет покрыть тестами [и в последствии вносить в реализацию правки]?».
Еще очень TDD и иногда BDD заходит для нетривиальной бизнес-логики. В таких случаях противоположный формат «сначала реализация, затем тесты к ней» даже воспринимается как своеобразное подыгрывание себе и уже попавшим в реализацию потенциальным багам. Хотя, откровенно говоря, в случае с классами и методами с более простой начинкой найти достаточное количество самодисциплины для TDD бывает трудно (да и нужно ли?). :)
На данный момент тестами покрывается все. Единственное что — довольно часто сперва строится логика, которая реализует задачу, а потом — пишутся тесты.
В последних проектах тестами покрывается весь написанный код, независимо от того — критический он или нет. Больше всего юнит-тестов, так как много бизнес-логики, но и интеграционных хватает
На Java і Scala пишу тести завжди, бо вживаю методику TDD: визначити елементарну вимогу, створити для неї тест (із назвою, яка відображає вимогу), переконатися, що результат тесту негативний, додати потрібну функціональність, переконатися, що результат тесту тепер позитивний, почистити код. Просуватися вперед при цьому малими кроками.
Переваги:
якщо зіпсував якусь уже зреалізовану функціональність, одразу це побачиш і виправиш;
легко реалізуєш складну функціональність;
завжди бачиш, чи в потрібному керунку змінюється твій код.
Недоліків згадати не можу.
Покрываю все \о/
Я еще и матом часто покрываю код, написанный не мной.
Жаль, что код не умеет говорить.
Угу, зато тесты умеют. Хорошо, когда они есть.
Какой у вас в среднем процент покрытия ?
Я процент специально не считаю, но свою логику достаточно хорошо покрываю тестами. Если взять отдельный сервис, то в нем покрытие может быть
Что именно бывает? Что я свой же код через полгода начинаю матами крыть и ругать за кривые ручки себя. Да и часто.
А я наоборот думаю, какой умный человек писал этот код! Оппа, да это же я! %)
Мне бы так научиться. Нехорошо как-то себя ругать, даже в морду за это себе не дашь.
Раздавите пызурь на двоих — может подружитесь %)
Пробовал. Не работает. Хочется еще и ногой себе в челюсть бить после раздавливания пузыря.
Хочется еще и ногой себе в челюсть бить после раздавливания пузыря.
Это работает?
Та я работаю дома, один, так что этого никто не слышити вряд ли оно влияет на качество продукта 😊.
то е читерство ((
Пишем, Behat для API, PhpSpec для юнит тестов. Раньше, когда был проект без SPA фронтенда еще писали e2e на селениуме, тот еще был ад.
TDD использую практически всегда для API, на уровне юнитов зависит от задачи, если много доменной логики то сначала пишу код, потом тесты и в процессе рефакторю. Если что-то вроде pure function для разных подсчетов с определенным input-output, сначала пишу тест с датасетом.
Последние полгода код без тестов не релизится на нашем проекте, за редким исключением.
Подход «сначала тесты» использую иногда, но не считаю догмой.
Последние 3 года, работая php symfony разработчиком не в аутсорсе, пишу юнит-тесты на каждой работе. На последней — традиции писать их не было, но моими стараниями она появилась за чуть более чем полгода. Благодаря большому покрытию мы перестали бояться рефакторинга и обновления версий зависимостей — держим последнюю LTS версию.
Юнит-тестами покрываю не всё, только те слои, где есть бизнес-логика, но там стремлюсь к 100% coverage по методам. Контроллеры, репозитории, классы api методов, эвенты, велью обжекты и все такое прочее, где нет бизнес-логики не покрываю вообще, хотя встречал в одной из команд и такую практику — частично покрывать энтити и репозитории, где по DDD есть какая-то логика над объектами.
Интеграционные тесты на phpunit и немного на behat раньше приходилось писать, но в текущей команде есть кому писать тоже самое на java selenium из тестировщиков, поэтому разработчики этим не занимаются.
Считаю юнит-тесты очень полезными. В командах, где они обязательны, разработчики приучаются сразу писать тестируемый код. Это входит в привычку и даже в аврале количество плохого кода значительно снизится.
TDD пробовал использовать для очень сложной бизнес логики, там себя оправдывает, но использовать его постоянно для рядовой рутины — оверхед.
Немного мудрости вам в тему Ian Cooper — TDD, Where Did It All Go Wrong.
Лично я классическое TDD не использую. Во-первых, для сложной алгоритмической логики часто возникают сложности с тем, чтобы воссоздать условия, в которых должна выполняться функция. Во-вторых, часто эти условия меняются.
А вот функциональные тесты очень даже использую, когда программа под valgrind тестируется полностью на заранее подготовленном хитром тестовом наборе. Брать в руки саблю, рубать и крошить становится легче в моральном плане.
бехат, функциональные, интеграционные, юниты. Понятное дело, что не всегда все слои нужны. Работать без них — ацкий геморрой, но это зависит от масштаба проекта
В пет-проекте стараюсь писать тесты сразу (интеграционные — на каждый эндпоинт несколько тестов на корректность ответа в разных ситуациях, юнит-тестами не заморачиваюсь). Не TDD. Большой плюс — немного больше уверенности что новым кодом не сломал старый. Большой минус — тесты долго писать.
А на работе — нужно быстро пилить фичи, какие там тесты.
Пишу по TDD, от тестов отказываюсь только когда совсем задница в огне. Придерживаюсь мнения Р. Мартина, что программисту не нужно объяснять заказчику (менеджеру, product owner’у и т.п.) необходимость написания тестов. Вы профессионал и вы знаете лучше них. Написание не является чем-то отдельным, а является составной частью разработки. Если бы на меня давил менеджер и просил не писать тесты (не в экстренных случаях, а на регулярной основе), я бы крепко задумался о смене работы, ведь на кону — моя профессиональная репутация. Программистов, отказывающихся писать тесты без всякой на то причины, считаю за плохих профессионалов (по крайней мере, в области enterprise-разработки, где поддержка существующего кода составляет львиную долю работы).
Недостатки TDD:
— если не уделять тестам такое же внимание, как и обычному коду (а значит и рефакторить их), то они очень быстро становятся бременем. Нужно хотя бы немного знать о паттернах и анти-паттернах в написании юнит-тестов, чтобы писать поддерживаемые тесты.
— в прототипировании юнит-тесты — лишние, но с большой жирной оговоркой — как только прототип готов и гипотеза доказана, прототип нужно выбрасывать и писать по новой с правильным подходом
— при старте нового проекта в самом начале требуется время для настройки тестовой обвязки и прочего, с этим связанного
— TDD, как и любая дисциплина или умение, требует начальных инвестиций для того, чтобы им овладеть
Преимущества:
— отсутствие страха перед рефакторингом и внесением изменений в существующий код, что уменьшает code rot
— быстрая обратная связь
— менее связанный дизайн, code visibility
— тесты как документация
Вы профессионал и вы знаете лучше них.
Но деньги у них, они любят спрашивать объяснений зачем столько времени и могут нанять кого-то другого
Стараюсь не задерживаться долго в таких конторах — к счастью, пока проблем с выбором работы нет. Если менеджер вам не доверяет в профессиональном смысле и требует отчитываться, что вы конкретно кодируете, то это явно нездоровые и не партнерские отношения.
я только что выше написал практически тоже самое (до того как увидел этот комент) =)
Полностью поддерживаю
Чистый TDD («сначала тест») не практикую. Пишем и юнит-тесты, и интеграционные (как с замоканными зависимостями, так и для реальной инфраструктуры) в зависимости от проекта (интеграционные — мастхэв во всех случаях с максимально возможным покрытием). Если Вы приходите на устоявшийся проект, где всё плохо, то начинать с юнит-тестов — очень, очень плохая идея, т.к. рефакторить проект полностью, очевидно, никто не будет. Поэтому итерации разгребания стоит начинать с конца — от высшего уровня интеграции спускаться к юнит-тестам, чтобы максимально быстро привести систему в состояние управляемости, понятности и предсказуемости. Если же проект с нуля, то лучше сразу начинать (или переписывать MVP) хорошо по классике, с юнит-тестов и так далее вверх по интеграции.
Если же проект с нуля, то лучше сразу начинать (или переписывать MVP) хорошо по классике, с юнит-тестов и так далее вверх по интеграции.
На самом деле, как минимум в одном источнике (Growing software guided by tests) рекомендуют начинать как раз с высокоуровневых acceptance-тестов, спускаясь далее до юнит-тестов в обычный цикл TDD. Мне тоже кажется такой подход более удобным.
На самом деле, как минимум в одном источнике (Growing software guided by tests) рекомендуют начинать как раз с высокоуровневых acceptance-тестов, спускаясь далее до юнит-тестов в обычный цикл TDD.
Объясните плз пошагово, не совсем понял алгоритм. Т.е., сначала объявляем каркас из структур данных, пишем сразу все высокоуровневые тесты, и только потом покрываем реальную реализацию по мере её имплементации? Если так, я это слабо представляю в реальности — выглядит похожим на подход а-ля «архитектор-космонавт» со 100% уверенностью в правоте своего дизайна). Это как минимум очень дорого и высок риск улететь в трубу при смене бизнес-требований (т.к. реализация будет «ожидать» написания всех этих тестов). Не буду утверждать, что это не работает, но выглядит сомнительно... на самом деле, единственный рабочий вариант, который приходит в голову — исключительно маленькие монолиты или клиентские программки (микросервисы — нет, т.к. начинать с них сразу — уже риск).
Нет, подход в принципе такой же, как в «обычном» TDD, только перед разработкой очередной большой фичи (или большого сценария использования) вы пишете для нее acceptance-тест. Это может означать совершенно разные вещи, совершенно необязательно ему быть end-to-end тестом в каноническом понимании. Например, для Spring Boot-сервиса это может быть обычный «интеграционный» тест для всего приложения (@SpringBootTest, с реальным web-окружением, но, допустим, с in-memory БД, либо с базой, запущенной через test containers).
Как только базовый acceptance-тест готов, переходите к привычному циклу TDD. Тут существует множество вариантов, но в книге предлагают идти от входов к выходам, т. е. например в вышеупомянутом случае начинаете с юнит-тестов контроллера и реализации контроллера и его зависимостей, и постепенно опускаетесь ниже уровень за уровнем. Такой подход работает для меня в большинстве случаев.
Вот как это выглядит графически: imgur.com/a/PrbCVl9
Минус такого подхода в том, что тесты долгое время красные. Что не ок по ряду причин. Очень рекомендую видео, которое закинул выше.
Минус такого подхода в том, что тесты долгое время красные.
Если речь о новых фичах, и планируется несколько слоёв тестов, то с ними работать придётся в любом сценарии: хоть снизу вверх, хоть сверху вниз, и пока всё не сделается, таск не будет считаться готовым/тесты будут красными. Но ведь они будут красными только для ветки с этой фичей, поэтому не совсем понятно, почему это не ОК.
P.S. Видео уже бросил в закладки.
они будут красными только для ветки с этой фичей
А сколько эта ветка будет жить? Если от силы день — не проблема, наверное.
Ну, пусть 2 недели — количество слоёв тестов для добавления этой фичи от этого не изменится же.
2 недели
В этом случае появляется другая проблема — Continuous Isolation. И, все-таки, приятнее когда большую часть времени тесты зеленые.
В этом случае появляется другая проблема — Continuous Isolation
Похоже на то, что она неизбежна — человек обязан что так, что так выкатить всю цепочку перед мерджем.
И, все-таки, приятнее когда большую часть времени тесты зеленые.
У меня, кстати, другая философия). Если есть проблема, пусть лучше они будут красными.
Похоже на то, что она неизбежна
Если есть проблема
Так проблемы же пока нет — есть не до конца реализованная фича.
trunkbaseddevelopment.com
С некоторыми вещами со старта не согласен). Используется допущение, что взаимозависимые API будут очень часто меняться, но ведь это банально похоже на плохой дизайн/код. И «решение» в виде новой стратегии ветвления я бы не назвал элегантным... скорее нужно задать вопрос, а почему так получается, что мердж или rebase за 2 недели превращается в ад. Поправьте, если не так. Пока я за GitFlow обеими руками).
Пока я за GitFlow обеими руками).
Оно в какой-то момент кликает. У меня тоже не сразу кликнуло и до этого я активно продвигал GitFlow в предыдущей команде — все же лучше, чем ничего.
Что помогает понимаю — это то, что пока вы работаете в ветке другие члены команды не видят ваших изменений. Вы можете менять/рефакторить одинаковые участки кода и это приводит к конфликтам.
Были такие ситуации (требовалось много фич и фиксов в одном и том же «денежном» компоненте, поэтому работало >1 человека), но это было исключение. Правило: иногда пару строк кода, что не составляет проблемы. С другой стороны, если пишется новый тест, то может произойти следующее: в одном и том же месте фиксится один баг, но фикс ломает новую фичу, которая в процессе. Предложенный подход от этой (гораздо более насущной) проблемы не избавляет, к сожалению (т.к. вряд ли от неё теоретически можно избавиться), а смерджиться — ИМХО, несложно.
Например, дев1 и дев2 работают над какой-то строкой, которая друг-другу что-то ломает. Как решить этот конфликт? дев1 скажет «мне надо так», дев2 — «мне надо эдак». Чтобы узнать, что произойдёт, нужно, чтобы или один, или два, или оба... попробовали чужой кусок кода у себя. То же самое, собственно. Или сценарий: дев1 уже закоммитил. Если после этого дев2 внёс изменения и что-то сломалось, он должен будет ещё частично разгребать и таск дев1... точно то же самое будет и с «длинной» изоляцией.
В общем, со стороны кейс рассчитан на хаос, когда каждый день люди работают над одним и тем же кодом, и тогда будет легче. То есть, merge — это страшно, а такое распределение задач на постоянной основе — нет... :)
Это не зависит от применения или неприменения TDD. Это больше вопрос подхода к разбивке работы на меньшие части. В новой функциональности найдите самую минимальную функцию, для которой вы можете написать acceptance-тест и реализуйте ее. Затем добавляйте дополнительные возможности понемногу, модифицируя тот же acceptance-тест или добавляя новые. Это пресловутое вертикальное деление историй (vertical story slicing), просто в другом контесте.
Если это можно комитить в мастер хотябы раз в день и тесты при этом не красные — ок, как по мне.
Понял, в принципе так выглядит вполне ОК. Ну и ещё добавлю здесь ремарку, из-за которой уже летели помидоры в других темах — если код хорошо структурирован, то на юнит-тесты в таком случае останется относительно мало покрытия, т.к. через вызовы паблик методов в общем случае ДОЛЖНЫ перекрываться и private/protected/internal.
я собственно тоже. чистый TDD хорошо смотрится в идеальном мире разработки, но мало применим при методологии «полный ... аджайл» , когда спецификации меняются по 10 раз на дню. Пока ты писал тест , окажется что писать уже нужно что-то другое. Соответственно время потрачено впустую . Чаще делаю наоборот, сначала кодинг задачи, потом тест. На некоторые участки системы состоящие из страшного легаси кода, написать юнит тесты не представляется возможным в принципе (потому что написано кривыми руками через ж..пу). Такие вредные места покрываем интеграционными тестами, которые тестируют бизнес-функцию а не низкоуровневый код.
Чаще делают наоборот, сначала кодинг задачи, потом тест кодинг следующей задачи.
Fixed.
Я от чув, не знаю чи це правда, що в facebook (крім того, що там немає к’юеїв) юніт тести теж не в фаворі. І якщо це так, то це удар по віруючим в TDD і 90% покриття.
А фейсбук это то на что нужно равняться?
На Цукерберга, звісно, ні. Але туди набирають, типу, кращих програмерів, і під них створена своя культура і процеси розробки софта. І якби їх примушували робити якусь фігню, писати як за царя гороха, ігнорувати сучасні практики, то вони б, мабуть, з фейсбуку розбігалися б швидко.
в каком то интревю марк рассказывал что внутри у них есть конструктор фейсбука, где можно запустить симуляцию сети с любыми настройками, и проверять как это все будет работает
вероятно тесты при такой мультивариативности — бесполезны
А я слышал что фейсбук случайно снимает с карты деньги за рекламу, которую ты не заказывал. Причем жертва карту когда-то привызывала в инстаграме и потом удаляла. А она оказалась как-то в пеймент-методах в фб.
Я бы не равнялся на корпорации с громкими именами. В них далеко не все идеально, а знамениты они только тем что умеют зарабатывать деньги.
Не говоря уже о 100500 утечек данных по разным причинам.
Не удивительно что продукт такой говёный в итоге. Дизайн убогий. Банальнейшие фичи типа хоть какого-то форматирования постов — отсутствуют. 2018 год идёт к концу.
що в facebook
facebook, який випадковим чином пропускає повідомлення, ніколи не може показати одну і ту же стрічку, кожний третій-четвертий раз зупиняється після десятка повідомлень з написом «а зараз більше нічого немає», один раз на двадцять-тридцять відмовляється відіслати коментар...
Я б не пишався такою «роботою».
І якщо це так, то це удар по віруючим в TDD і 90% покриття.
Це удар лише по тим, хто вірить в якість сервісу facebook :)
там немає к’юеїв
да ладно ?
те, що там немає клікерів, як на укр. галєрах, не означає, що немає QA процесу.
юніт тести теж не в фаворі
враховуючи, що ФБ релізиться декілька разів на день автотести там ой який великий пріорітет
Вот прям счас пишу :) Отвлекся, пока билдится :)
Юнит тесты и интегрейшн тесты юзаем. Покрытие нашего более-менее нового кода близко к 90%, покрытие старого говнокода близко к 0 потому что он не тест-френдли
потому что он не тест-френдли
ИЧСХ, работает. Чего не скажешь про новый — в нём работают только тесты.
Если серьёзно, то когда разработчикам тестов начнут платить столько же, сколько и разработчикам кода, станет понятно что не нужно каждую строчку покрывать тестами.
Тест, идущий тем же путём, что разработка — никогда не исправит проблем разработки. Правильный тест — это обратная связь. Он может встать поперёк горла даже автору тех.задания.
Написание хороших тестов может занимать столько же, а то и в разы больше времени написания кода. А теперь попробуйте это продать клиенту. В нашей суровой реальности — тесты это непозволительная роскошь)) Тесты пишут обычно в продуктовых компаниях, но в большинстве случаев из-за жестких дедлайнов, это тесты ради тестов, которые покрывают совсем тривиальные кейсы. И после выхода в прод, оно все равно падает, хотя тесты все зеленые)
Вижу подход геймдева ☹️
Мне кажется в геймдеве вообще плевать на качество, так как продукты одноразовые. И быстро фиксят только совсем зашкварные баги)
Быыыыыыыы ... ы..ы.....ыыыыы..ыстро
Зато когда упало, можно сказать «я не виноват, вон тесты же проходит, это QA виноваты».
Так то ХОРОШИХ тестов. А разве кто-то оценивает качество тестов? Оценивают процент покрытия кода. «Лучший» тест — тупо контрольная сумма текста исходников :)
как правило нет, на аутсорсе обычно время более критично, чем стабильность решения.
То есть у вас вообще нет тестов? Но тогда вам нужен целый штат мануальщиков
За 15+ лет всего один раз в команде был тестер. Ниче, работает все это както. Некоторый комплексы зарабатывают больше миллиона в год владельцам. И все без тестов както работает. Из «тестов» есть только минимальные функциональные проверки nagios. типа проверки, что сервис вообще работает.
Еще раз. Обычно на аутсорсе требуется сделать все на позавчера. Ибо на сегодня уже не сделал более дешевый индус или ктото из локальной команды. Времени на тесты тупо нет в распорядке. Иногда даже на необходимый рефакторинг со скрипом есть. Необходимым называется рефакторинг, без которого новую часть системы не впихнуть.
Ниче, работает все это както.
Ребят, не все программисты работают в зарегулированных командах или галерах. И даже не все — вообще в командах.
Работает, все нормально работает. Не работало бы — писали бы тесты.
Ну я примерно к этому выводу и пришел, читая ваши посты выше. Это то, что можно назвать «ковбойское программирование». Типа «я ошибок не делаю, я шо не мужик?» или «- ты точно в новой версии регрессий не сделал? — мамой клянусь!». Да, может работать в определенных окружениях, типа одиночки-супергероя, выпускающего релизы раз в полгода.
Но в большинстве окружений — это будет реально пытка. Код начнет гнить уже через
Да, выбирая из такого радиоактивного проекта и «галеры», где поставлены хорошие QA-процессы, кастомер не лезет не в свое дело и все разработчики довольны и сконцентрированы на творческой работе — я выберу «галеру» any fucking time.
Главное успеть свалить с проекта или галеры до того момента, как проект тебя похоронит под собой, когда рассыпется.
Ошибки делают все. Причем и в тестах тоже.
Заказчик просто выставляет приоритеты. Ну почемуто он не гниет через
Я УМЕЮ писать тесты. Но фриланс он такой, ковбойский, да. Что ж тут делать то?
Нравится вам галера — выбирайте, никто вам слова не скажет, все взрослые люди.
Что вы хотите сказать своим сообщением, Александр? Вы не согласны с чем-то или просто хотите мне сказать, что вы умеете писать тесты?
Я считаю, что вы неправы. Ничего не разваливается через пару месяцев, работает годами, работать так можно и часто приходиться. Да, требует большей квалификации. Да, в окружении типичной галеры, где все друг на друга валят отвественность — нельзя.
А сколько человек меняют код на подобных проектах?
Так я по-моему признал, что для проектов определенных конфигураций это может работать.
Можете дополнить, но я бы видел это так:
— проект, который ведет один человек и не собирается его бросать (волк-одиночка)
— серия однотипных краткосрочных проектов (напр. фриланс)
— research-проекты, PoC
— очень специфичные проекты вроде описанного выше
Я убежден, что для типичного enterprise-проекта такой «ковбойский» подход — смертелен. Признаки такого проекта:
— проект живет и развивается дольше, чем отдельный разработчик на нем работает
— стремится к коротким циклам доставки (в идеале — continuous delivery)
— область грядущих изменений невозможно предсказать
— проект не является слишком специфическим (напр. выше один собеседник описал проект, который явно слишком специфичен и, очевидно, требует иных подходов)
Если такие проекты разрабатывать по вашей «методике», мы получим все то, что я описал выше. Это мой личный опыт, опыт многих моих коллег на бывших проектах, опыт, который также транслируют нам известные гуру в области OOD и Agile.
Отбрасывая ваши очевидно пассивно-агрессивные нападки в стиле «типичной галеры», согласны ли вы с этим?
Кстати о птичках — а ведь почти все, на чем вы работаете, написано безо всяких ТДД, а регрессия появилась только в начале
Все операционки, все сетевое, все базовые библиотеки, все крупные СУБД — все написано без каких-либо аджайлов по строгим ватерфалам и работает десятилетиями.
А на аджайлы со скрамами в энтерпрайзе принято отдавать только то, что в принципе к бизнесу далеко сбоку и будет относительно пофиг, если оно вообще не взлетит. И вот именно на таких проектах наши галеры воспитывают большинство юных программистов. Так что зазнаваться не стоит.
Тестирование — это хорошо и обязательно. Интеграционное, регрессионное, нагрузочное, секюрити и т.п. Но писание параллельно еще одного проекта на каждый чих основного вместо создания спек и документации ИМХО лютый перебор.
Все операционки, все сетевое, все базовые библиотеки, все крупные СУБД — все написано без каких-либо аджайлов по строгим ватерфалам и работает десятилетиями.А на аджайлы со скрамами в энтерпрайзе принято отдавать только то, что в принципе к бизнесу далеко сбоку и будет относительно пофиг, если оно вообще не взлетит.
Мне кажется, вы неправильно понимаете Agile, взгляните на вот эту статью от сами-знаете-кого: blog.cleancoder.com/...raftsmanshipMovement.html
Agile was never about project management; but that’s what they’ve turned it into. Agile and project management are utterly orthogonal things. Agile is not a better way to manage a project. Agile has nothing to do with managing a project. Agile is a set of values and disciplines that can help a relatively small team of software crafts-men and -women build small to medium sized products.
Я совершенно с этим согласен. Как говорится, «Scrum is more than standing up and burning down».
По поводу сравнения проектов типа enterprise с проектами типа операционных систем (я так предполагаю, вы подразумеваете open source?) — это сравнение квадратного с зеленым. Совершенно разные модели работы с кодом, совершенно разная динамика проектов, совершенно разные размеры кодовых баз, совершенно разные структуры проектов. Кроме того, Linux разрабатывается с какого, с
Так что зазнаваться не стоит.
Я-то не зазнаюсь, а вы, судя по тону коммента — таки да ;)
Мне кажется, вы неправильно понимаете Agile, взгляните на вот эту статью от сами-знаете-кого
Сколько «гуру», столько и трактовок. Сильно христианство напоминает.
По поводу сравнения проектов типа enterprise с проектами типа операционных систем (я так предполагаю, вы подразумеваете open source?) — это сравнение квадратного с зеленым.
Почему? Кодовая база Windows и MS Office вполне сравнима. И вполне сравнима с кодовой базой Оракла. И нет, я имею ввиду все операционные системы, т.к. в подавляющем большинстве они разрабатывались до появления идей аджайла и тем более ТДД.
Я-то не зазнаюсь, а вы, судя по тону коммента — таки да ;)
Отнюдь. Я вообще кодер — так себе. Я хорошо умею искать чужие ошибки, но не более того. Иногда ошибкой является весь проект или даже бизнес-решение о нем.
А на аджайлы со скрамами в энтерпрайзе принято отдавать только то, что в принципе к бизнесу далеко сбоку и будет относительно пофиг, если оно вообще не взлетит.
Либо эти «аджаилы» это такой себе подзамаскированный ватерфал со спринтами и тасками.
Все операционки, все сетевое, все базовые библиотеки, все крупные СУБД — все написано без каких-либо аджайлов по строгим ватерфалам и работает десятилетиями.
Принципиальная разница только в том, что где сейчас спринт
Но рано или поздно обратная связь с правкой требований всё равно возникала и применялась. И все компоненты того, что сейчас agile, присутствовали и применялись.
а регрессия появилась только в начале2000-ных.
О какой регрессии речь?
А на аджайлы со скрамами в энтерпрайзе принято отдавать только то, что в принципе к бизнесу далеко сбоку и будет относительно пофиг, если оно вообще не взлетит.
Может, вначале было так, но не сейчас.
Сейчас разница только в том, что для «серьёзных» задач тщательно прорабатываются спецификации, часто — особыми людьми, которые умеют предсказывать маргинальные случаи, возможные проблемы развития, и так далее.
Но писание параллельно еще одного проекта на каждый чих основного вместо создания спек и документации ИМХО лютый перебор.
С чего вы решили, что это «ещё один проект»?
Принципиальная разница только в том, что где сейчас спринт1-2 недели, тогда итерация могла быть и несколько лет.
Не соглашусь. Принципиальная разница именно в:
Сейчас разница только в том, что для «серьёзных» задач тщательно прорабатываются спецификации, часто — особыми людьми, которые умеют предсказывать маргинальные случаи, возможные проблемы развития, и так далее.
Ибо подход «а нафиг та проектная документация и спецификации, давайте сразу что-то лепить на модном фреймворке по юзер сторям» и рождает монстров типа ТДД.
С чего вы решили, что это «ещё один проект»?
По трудозатратам и размеру кодовой базы.
При этом в основе лежит в корне неверный постулат о том, что пишущий тесты в состоянии предусмотреть абсолютно все нештатные ситуации, а пишущий код разработчик — почему-то нет. Даже если это одно и то же лицо.
Не совсем. Говнокодер — это тот, у кого и тесты сомнительного качества
а кто ж тогда такие как Денис?
Просто рисковые корсары ;)
Конечно же нет, с тестами ощущения не те
Зальём в продакшен — тестировщиков там больше
©
Стараюсь писати тести на складну та важливу логіку, яка буде стабільною довгий час, або коли помилка може зробити великі збитки.
Коли відсутнє повне розуміння, як вирішити задачу, то пишу тест щоб зафіксувати, що хочу отримати, далі пишу код щоб тест пройшов, так
Пишу коли хочу замінити старий код який без тестів, тоді спершу покриваю, а далі видаляю старий.
Пишу, щоб порівняти швидкодію та використання пам’яті.
Відмовляюсь від тестів коли треба швидко реалізувати обгортку над функціоналом.
Коли це менш важлива частина і скоріше за все буде змінюватись.
Коли треба щоб швидко залатати.
Часто TDD залежить від настрою та складності задачі:
Коли знаю як вирішити складну задачу то можу спершу зробити рішення, а далі покрити тестом.
Якщо рішення дуже просте, та все одно важливе: то можу написати тест і коміт з «test before code 5 percent good price QRT-315», а наступний вже буде з «pass tests QRT-315»
в Le Boutique будь-які зміни в оформлені замовлення чи корзині треба покривати тестом, інше або обговорювали на плануванні або за бажанням розробника.
А от в outsource залежить від того чи змогли продати ці тести замовнику
Олексій Пєніє
Денис Зайцев
anonymous
Сергей Черепанов
Oleksandr Besedin
Дмитрий .
Vadim Kopanev
Anton Martynenko
Андрей Литвинов
Dmitry Bugay
devv
Alexander Merkulov
Grez
Bot Bot
Dmytry Lehenkiy
Valentin Nechayev
Andrio Skur
Anton Martynenko
Александр Шевченко
Mykola Kolisnyk
Oleksandr Golovatyi
Valentin Nechayev
Александр Шевченко
Konstantin Mikhailovskiy
Dmitry Derevyagin
Sergiy Morenets
Oleksij Lupandin
Elena Morgun
Sergiy Morenets
Oleg Gasul
Mike Gorchak
Alex Fogol
Никита Ткаленко
Konstantin Uvarin
Artem Frolov
Андрей Литвинов
Andrew Sevastianov
Anton Khristiansen
Gennady Dogaev
Андрей Балагута
Gennady Dogaev
Андрей Балагута
Max Shnurenok
Max Shnurenok
Victor Mikhaylov
Viacheslav
Иван Довгай
Viacheslav
Андрюха Цибрій
Elena Morgun
Witalij Berdinskich
Oleg Zarevych
Oleg Gasul
Victor Mikhaylov
Олексій Пєніє
Сергей Черепанов
Alexander Merkulov
Tim Tretyak
Ярослав Характерник
Лучшие комментарии пропустить