Comments 6
Да, на самом деле я тоже задумывался над этим.
Смотришь примеры, а там: assert (4+3)==7
Ныряешь в большой и сложный проект и ... Как быть?
Или всё замокать, или сразу интеграционный написать :-)
Абсолютно не соглашусь с информацией о бесполезности "Покрытия"
Меня очень спасает gem 'simplecov', который показывает где я забыл покрыть код тестом. В итоге если покрытие 100%, я уверен что каждая строчка кода проверена.
Это всё частности. Главная пробема тестов - хомяки.
Мерлезонский баЛЛет Акт 1. Тесты
Так, юнит-тесты, нужны для проверки алгоритмов (либо устройств), оформленных по образцу конечных автоматов (КА). Ни к чему более они не применимы. По нормальному их называют integrity check tests (проверка целосности КА). То есть если функция не написана по образцу КА (что включает соответствующую на нё доку), то применять их запрещено (либо бессмысленно - как тыкать пальцем в небо).
Можно ли ими проверять всё дерево "бизнес-логики", если его внутрянка напихана черт-знает-чем? Ну, если после того, как данные попали в алгоритм и в нём не сидит рандомизирующих его состояния функций, то, да. Но (!) проверка будет гарантировать лишь работу на том множестве элементов вход->выход, которое подано/снято с алгоритма при тесте.
К примеру, мы проверили операцию для 2-х окошкек бухгалтера тёти Мариши, что при вводе 2+2 в базы пишется 4! И это честный и полный юнит тест! вводи 2+2 - всё будет в порядке. Но ведь, мы не проверили, к примеру, 2+0 и 0+2. А пусть тётя Мариша начисляет % на вклады. И ушлый альтруистично настроенный программист-оптимизатор, к примеру ещё допустил, что иногда начисления бывают нулевые. Но мысль о том, что на 0 руб могут начислить 2 (то ли рубля то ли миллиона $$$, а у нас и так бывает) - просто "взрывала" его мозг. Поэтому для такого случая он возвращал где-то в глубоко функциях ошибку "неверный аргумент", которая должна красным окошком выскочить на столе тёти Мариши. И этот "баг" мог не всплывать годами (Мариша то была тётка "старой закалки" и "у то акошка унь то не сувала"). Ну всё жжжж "работает"! А вот заболела/запила Мариша, и на 1 день на её место назначили Нину. А Нина - у нас (!) математик. Ну, какая разница, казалось бы, как в водить в окошки: 2+0 и 0+2?! Операция (+) же "ко-му-му-тО-тиуна" (им так в универститетах тых рассказвали)! Вот Нина и ввела...
2. Акт Второй. Хомяки
Не лучше ли было предоставить свой DSL, который сам как-нибудь под капотом запустит тесты?
Да я посмотрю, Вы, батенька, раскольник! Слова "свой DSL" хомякам произносить - запрещено! Они не то что начинают смотреть с опаской, а пугаются!
Животрепещущий пример:
О том и речь: хочешь разбирать грамматики - бери BNF/Bison/PEG и иже с ними, хочешь анализировать AST (он же - маркированый граф) - делай соответствующий DSL с паттэрн мэтчингом и специализацией.
Си не предназначен ни для первого ни для второго, и реализация перечисленного на нём будет кривой и корявой.(с) Я https://habr.com/ru/articles/871296/comments/#comment_27737516
Этот комметарий собрал 5 минусов, а дальнейшая дискуссия стоила мне 2 минуса в карму. И это где! Под статьей с заголовком (!) Анализ AST и рефакторинг кода в Clang!
Вы понимаете, какой там Clang у этих писателей и рефакторщиков будет?! Полный! И тут другие анализы сдавать нужно (совсем не AST-овские).
3. Акт Третий. "Что делать?"
Всё нынешнее ПО сейчас дырявое в усмерть (вон даже Боинги из-за "аусорса" не так давно падали). Но "управленцев" и "менеджеров" - это нисколько не смущает, ибо карманов их не касается: нафтанка качачается, бабульки в банчочках крутятся. А как оно там за окном машины с шофёром - так хоть пожар. :)
А другим-то, кто патриотически не присосан к бюджетам, что делать? - Очевидно, выгонять хомяков. Или у Вас предложения?
С другой стороны, мастера - уже пристроены: либо присосаны к бюджетам, либо извлекают прибыль сами. И врядли они откликнутся на зов покушать сладких пирогов от У.[словного]Яндекса, не говоря уже о шляпных галерах с жуликоватыми "оунерами". УЯндексы могут быть посланы: уж лучше батон с колбаской, да свой. :)
Так, "что делать"? - Закупить попкорна и наслаждаться шоу, равернувшимся у нас на глазах. Это лучшее предложение на ближайшие годы. :)
Всё так, в принципе. (Над комментарием и минусами взоржал, спасибо :)
Но кроме юнит-тестов умные люди придумали property-based тесты, которые иногда (иногда!) умеют закрыть почти все возможные состояния вход/выход и потому пригодны для тестирования бизнес-логики в виде чёрного ящика (когда на неё есть спецификация, разумеется).
В эрланге/эликсире, хаскеле и даже руби — реализации очень внятные и с некоторых пор я для всех своих данных поставляю рядом с основной логикой — генераторы, чтобы если кому надо потестировать их код рядом с моим, — мой будет готов поставлять объекты бесконечно, любых цветов и оттенков.
Рекомендую по теме почитать вот это:)
Как заработать 2.2 млн.руб себе и 18 млн.руб фирме без работников
Плохие тесты: кто виноват и что делать?