Комментарии 39
Все относительно. Фраза "пешеходы должны передвигаться по тротуарам" звучит правильно, если вы в городе. И не имеет смысла, если вы находитесь в лесу.
Ну а пример про 404 - это прокол программиста. Он не написал тест для сценария где внешняя система возвращает что-то еще помимо ожидаемых кодов.
Ну а пример про 404 - это прокол программиста. Он не написал тест для сценария где внешняя система возвращает что-то еще помимо ожидаемых кодов.
В статье не просто так сказано "при том же самом изначальном предположении" ;) Неправильным было именно оно, а чтобы написать тесты еще для чего-то - это надо было сначала хотя бы предположить.
В частности, у вас тоже ошибка - вы не предусмотрели, что внешняя система может вообще ничего не возвратить.
Потому да, ожидаемое поведение в нормальной ситуации - код 404, а дальше начинается нелюбимое многими "а что, если?" - а если код не такой, а если вообще с той стороны никто не ответит (где возможны два подварианта - "мы об этом узнаем быстро", например, не разрезолвился DNS, но это не единственный сценарий, и "мы об этом узнаем по тайм-ауту" - например, пакеты дропнулись по пути, но это тоже не единственный вариант - хуже, если TCP-соединение установилось, и на этом "всё")?..
Тогда почему же мы не применяем доказательную модель к различным методологиям и техникам разработки?
В крупных системах такие решения принимаются не на уровне отдельных разработчиков или даже команд, а спускаются им свыше в виде таких вот постулатов. Всей картинки в смысле why они могут и не видеть. Даже если архитекторы объяснили им свой vision на старте, то проблема в последствии повторяется при онбординге новых людей, которым уже ни кто ни чего персонально не объясняет.
Думаю, это не так. По моему опыту, чем больше спускается сверху, тем хуже работает команда. Но подобные вещи спускаются на практике весьма редко. Очевидно, это не забота архитектора и вне его полномочий. А менеджеров больше интересуют вопросы денег и сроков. Так что чаще спускают системы контроля времени. )) Но бывают исключения в виде авторитаристов на ключевых постах )
У меня на столе 30-минутные песочные часы, никакого шума :)
А как они дзынькают, когда 30 минут пройдёт? ну не пялиться же на них вместо работы...
Можно конечно приделать ардуину, чтоб задорный рингтон был, мощная rgb нотификация, зато не тикает, да. В опенспейсе. В песочных ничего не двигается, можно прям у монитора ставить, не отвлекает.
гхм, вы правда хотите отвлечься на «дзынь» если у вас работа прёт и вы не заметили, что время кончилось?
Я себе сделал программу, которая плавно рисует в system tray яркий цветной круг, с таким рассчётом, чтобы полностью дорисовать его за заданное время (я настраивал на 1 час). Когда круг заполняется, он начинает мигать — тогда я вставал из-за стола, выходил на улицу и обходил вокруг квартала — квартал был небольшой и занимало это минут пять. Вернулся, нажал мышью на мигающий круг — он перестал мигать и вообще исчез, и снова с нуля за час рисуется. Т. к. рисуется плавно, то вообще не отвлекает, но, когда мигает, начинает привлекать внимание, но если ты прям сосредоточенный-сосредоточенный, то можно и не заметить или какое-то время игнорировать, с другой стороны, если, наоборот, работа идёт туго, сидишь и мучаешь себя — можно в любой момент глянуть и примерно понять, сколько ещё осталось до перерыва.
Очень удобно, когда кто-то подходит побеспокоить, покажешь на часы: «у меня перерыв»
Культ карго как он есть: когда-то Большой Белый Разработчик использовал Тикающий Овощ, и стал легендой. Потом он деплойнулся за океан, но успел показать нам путь! Поэтому, сынок, вот тебе тыква с кукушкой, поставь её на свой рабочий стол. И не забывай кормить кукушку...
Единственно верный путь для чего?
Если единственно верный путь для того, чтобы код гарантированно покрывал все кейсы, то для этого есть любой язык с автоматическим доказательством теорем, например Idris
Однако в суровых реалиях почти всегда случается, что для бизнеса наиболее выгодно слепить очередной проект из кучи навоза и веток на фреймворке, специально именно для таких кейсов и предназначенном
Если взлетит - перепишут, если не взлетит - выкинут
то для этого есть любой язык с автоматическим доказательством теорем, например Idris
Со мной случилась однажды очень поучительная история — я нашёл ошибку в самоучителе F*, где много лет назад был пример с факториалом. Там в тексте рассказывалось про доказательство одного факта, а в коде доказывался совершенно другой. :-)
В общем, студент-медик должен быть небрезгливым и всегда внимательным.
Отличная статья. Специально зашел похвалить за то, как хорошо написано. Прямо отличное начало дня! :)
Слышали ли вы когда-нибудь подобные заявления?
И слышал, и сам так считаю.
Не понимаю программистов, которые имеют много лет опыта и не пишут авто-тесты. Для меня это люди навсегда застрявшие в джунах.
Меня сам по себе код не интересует. Слова Васи "он вчера работал" тоже. Я хочу в любой момент запустить тесты и увидеть, что они выполняются. Запустить покрытие кода тестами, и увидеть, что там 90+% (не показатель полноценного покрытия тестами всех ситуаций, но лучше чем 10%), так же как и не интересны проекты без CI/CD, где прод по старинке обновляют руками, регулярно сталкиваясь с проблемами, что Вася забыл выполнить какой-то там скрипт или миграции, и прод упал.
TDD!=автотесты.
Но давайте, для простоты рассуждений, приравним одно к другому. Автотесты не гарантируют ничего сверх того, что [не]выполняются автотесты. По результатам автотестов нельзя сделать осмысленный вывод.
Автотесты, равно как и другой баззворд в этом тредике это инструмент, который становится осмысленным только в руках сапиенса. Вот только сапиенс может применять ДРУГИЕ инструменты с тем же успехом.
Мир очень и неожиданно. разнообразен. Например, нужен ли CI/CD в тех проектах, где нет прода и нет D?
Автотесты не гарантируют ничего
О, обожаю такие рассуждения.
Добавлю:
Хорошее образование не гарантирует счастья в жизни - значит бесполезны
Большие деньги не гарантируют счастья в жизни - значит бесполезны
подствьте_что_угодно - не гарантирует счастья в жизни - значит бесполезны
Например, нужен ли CI/CD в тех проектах, где нет прода
Да, нужен. Вы никогда не работали с нормально настроенным CI/CD на GitLab? Когда чей-нибудь хреновый мерж реквест, который ломает билд проекта или тесты просто на уровне самого GitLab не может быть смержен? Соответственно не нужно даже тратить время на анализ плохого мерж реквеста - упал CI - иди чини. А уже после этого, мерж реквест который прошел CI глазами посмотрят другие программисты на ревью.
А у вас чёрный пояс по фигурному цитированию!!!
Нет, не бесполезны. Но не панацея. И не гарантия. Это как мыть руки -- какую-то болезнь не подцепишь. Но не значит "мою руки, значит ничем не заболею".
Куда делать CD, если делать некуда? Нет продуктива.
CI это не "упали тесты", CI это "наш код интегрируется с другим кодом". Этого другого кода может и не быть.
Куда делать CD, если делать некуда? Нет продуктива.
Вы в CI/CD видите только CD?
CI это не "упали тесты"
Разумеется. Если тестов нет, то и падать нечему.
Этого другого кода может и не быть.
Первый коммит в проекте?
В общем, чтобы не продолжать этот бесполезный разговор (я на последователей "тесты не нужны" насмотрелся в реальной работе, и то, какого уровня код они пишут), в заключение: работать без тестов и CI/CD можно, но для меня это тоже самое, что работать без git'а, а проект обновлять загружая файлики по FTP - можно, но это не уровень серьезного проекта. И в команде таких "программистов" мне находится неприятно. Хотя, конечно, каждому свое. Свинье и в грязи комфортно.
P.S. Код выполняющий работу - вторичен. Первичен - код который проверяет, что все работает как надо, и код который организует проверку и доставку нового кода. Но я понимаю, что эти слова за гранью понимания тех, кому "тесты не гарантируют"
Это вы наверное не сталкивались с подходом когда большая часть проверок отдается компилятору и системе типов. Как пример - scala zio (ну или Haskell). Там компилятор по рукам бьёт если забыть, к примеру, обработать ошибку. Ну и также там можно создавать dsl которые не позволяют в неправильном порядке пользоваться операциям.
Те в итоге при правильном подходе и дисциплине при код ревью тесты остаются только 3х типов.
1 - тесты которые написаны для сравнения концепций или скорости работы разных подходов
2 - интеграционные тесты по конкретным сценариям использования
3 - тесты на закрытие багов
Нагрузочные тесты оставим за скобками.
Это вы наверное не сталкивались с подходом когда большая часть проверок отдается компилятору и системе типов
Думать, что на каком-нибудь go писать юнит тесты не нужно это очень наивно)
P.S. Пока вы тут доказываете, что тесты не важны, я прямо сейчас на работе наблюдаю ситуацию, как функционал, который писался с такими же подходами отваливается в который раз на проде. А функционал нужный, затрагивает большое количество пользователей, которые уже звонят в техподдержку и не сдерживаются в словах.
Кстати, функционал на go, но что-то строгая типизация и умный компилятор не помогает)
Думать, что на каком-нибудь go писать юнит тесты не нужно это очень наивно)
Приводить go как пример языка с сильной системой типов - ну такое...
можете пояснить? мне казалось, что go — классический strongly typed язык
Иногда кажется, что из AGILE исчезает весь agile.
И "сертификации" тому явное доказательство. Вопрос: "шашечки или ехать?", -- как бы снят с повестки и всë более и более, как было справедливо замечено торжествует карго культ.
Напоминает то, что сделало с идеей КОММУНЫ КПСС/КПРФ
Отличная статья) можно было бы ещё добавить в список аналогичную веру в devops, continious delivery...
В отрасли - засилье неофитов. Сеньеры с 2х летним опытом не могут пропустить советы через призму своего опыта, которого еще нет. Поэтому к советам относятся как к откровениям и начинают исполнять все это как церемонии и обряды.
Программисты-экстремисты