ищем/пишем перевод

Зачем?

OK, прочитайте за меня и скажите, почему юнит тесты - это мусор пустая трата времени

Чтобы свет истины в массы нести, очевидно ) Как будто ты не видел здесь людей, которые не могут в английский.

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

или которым лень в английский :)

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

или которым лень в английский :)

Или которые не могут в английский, а всем говорят, что лень

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

Их много :(

Как leave заметил, читать 20-тистраничную простыню времени нет.

ок, гугел

пишем перевод с последующей публикацией на хабре.

Why Most Unit Testing is Waste

Почему большинство модульное тестирование отходов.

Так хабре своей и напиши.

Лол. «Беги лес, беги. Лес, которым управляют!» =)

Я пару страниц прочитал, нового ничего не увидел. Самопиар автора в наличии. Может, днём выкрою минут 15.

Не у всех уровень C2

Там В1 - максимум В2 в этом тексте.

If you find your testers splitting up functions to support the testing process, you’re destroying your system

дальше не читал

С тезисом согласен, но статья на 90% чушь, состоящая из передергивания.

Подтверждаю, у меня B2, статья читается легко.

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

Лень вчитываться, что автор предлагает взамен?

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

Лень вчитываться, что автор предлагает взамен?

В конце есть summary.

Типчики не спасают

No silver bullet, да.

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

Причем писать их будут негры из кенийских саванн (правда-правла).

На JS, чтобы уж совсем.

а что взамен? Писать или не писать юнит тесты?

Не, они могут только с типами. Чтобы на JS мочь, голова нужна.

Чтобы свет истины в массы нести, очевидно ) Как будто ты не видел здесь людей, которые не могут в английский.

тут старая мысль про голод, рыбу и удочку.

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

Это ты про статику щас говоришь. В динамике — именно голова. См нпр smalltalk. С JS примерно то же самое.

Функциональные тесты

я уже их писал.

Потому же, почему и аджайл в целом :) Плохим программистам не поможет, хорошим - не нужно :)

Так про что угодно ляпнуть нужно. Лифт сильным не нужен, слабым не поможет.

Keep regression tests around for up to a year — but most of those will be system-level tests rather than unit tests.

if X has business value and you can text X with either a system test or a unit test, use a system test

дяде плохо, дядю надо лечить

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

Хорошим помогает. Вернее, может помочь. Он решает проблемы не в области программирования, а в области процессов.

Не читал, но автор пытается мыслить чёрно-белыми категориями.

которые занимают кучу времени на прогон

Нужно инвестировать в окружение. БД в памяти, моки внешних сервисов и так далее.

количество которых растёт в геометрической прогрессии

Ерунда, их количество растет линейно с ростом функциональности.

а их поддержка превращается в ад уже через несколько спринтов

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

Нужно инвестировать в окружение. БД в памяти, моки внешних сервисов и так далее.

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

Ерунда, их количество растет линейно с ростом функциональности.

во-первых, почему мы ограничились ростом функциональности? сводить тестирование сложной системы к банальному черному ящику с покрытием только требований - кратчайший путь к факапу и потерям времени на тест-дизайн и дебаг приложения
во-вторых, даже если рассмотреть только рост функциональности, без покрытия тестами внутренних изменений системы. допустим, есть система из N модулей, с одной точкой входа и M точек выхода. добавим на вход первого модуля 1 переменную (соответственно +1 точку выхода), получим условные +2 теста на первый модуль (позитивный и негативный) и столько же на все зааффектанные модули при модульном тестировании. при функциональном тестировании - +2*M тестов независимо от того, зааффектаны все модули или только некоторые. итого, максимум 2*N при модульном против гарантированных 2*M при функциональном. это не считая того, что в 99% случаев точек выхода больше, чем модулей в системе (каждый модуль реализует какую-то логику, соответственно плодит точки выхода)

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

конечно, за 7 лет в QA - ни разу. поддержка функциональных тестов на порядок сложнее по причинам, описанным выше: любое изменение надо тащить через всю систему, не ограничиваясь измененным модулем

В Спарте так и было.

Все понятно. Ни разу на видел, что бы QA писали нормальные тесты. Твои рассуждения про долгий тест-дизайн и дебаг это подтверждают.

Ни разу на видел, что бы QA писали нормальные тесты.

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

Как leave заметил, читать 20-тистраничную простыню времени нет.

времени нет...

...потому что

......нужно успеть написать тесты! :-D

Нет, поскольку семья, 2 работы и увлечения между делом.

я не против послушать, как удержать рост количества функциональных тестов в разумных рамках.

Короткий ответ, многократно повторяя правильно Парето (20% усилий дает 80% результата), пока не будет приемлимого результата.

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

Нужно исходить исключительно из целесообразности

Это напрямую противоречит всем методологиям тестирования. «тестирование из целесообразности» не нужно и бессмысленно просто по своему определению. Все такие тесты можно смело удалить и ничего не потерять. Полезные тесты - это те, которые выходят за рамки целесообразности.

Лол. «Беги лес, беги. Лес, которым управляют!» =)

http://itmages.com/image/view/2505965/d6e4a0d9

Нужно исходить исключительно из целесообразности, а не «давайте покроем все возможные кейсы между модулями»

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

покрываются некоторые важные сценарии, которые с наружи не видны

если ваша система настолько хреново документирована, что важные сценарии не видны членам команды - у меня для вас очень плохие новости

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

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

//пмсм, человеку, который пишет «приемлимого», «приделах» и «с наружи», высказывать мнение о тестировании должно быть запрещено законом

Ерунда. Все ваши проблемы как раз из-за бездумного следования правилам. Здравый смысл рулит.

а чем функциональные тесты отличаются от этих.. ну как их там.. а .. интеграционных!

Полезные тесты - это те, которые выходят за рамки целесообразности

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

Скучные выходные, да?