LINUX.ORG.RU
ФорумTalks

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

 


0

2

Некоторые разводят срачи, мол как можно в 2025 писать без полного покрытия тестами, фаззинга и не на Rust. Стоит бурлёж до неба. Факт бурлежа указывает на неоднозначность вопросика и на отсутствие чётких формулировок у каждой из сторон, скорее всего у той, которая предлагает забить на тесты хрен.

Пришла в голову чёткая понятная формулировка НЕНУЖНОСТИ. Потому, что это как предварительная оптимизация. Аналогия абсолютно точна! Утверждать, что всё должно быть покрыто тестами и фаззингом и быть написано на rust - то же самое, что утверждать, что всё должно быть написано крайне оптимально сразу, ведь ты не знаешь решат ли твою функцию повызвать 1 млн раз в наносекунду и дадут ли потом время переделать!

И предварительно оптимизировать можно, и писать на всё тесты, но у этого есть ЦЕНА. В среднем платить её никому не усралось, ценнее выкатить фичу. Упадёт на проде - тогда и починим (убьют - тогда и приходите). Бизнесу дешевле полдня полежать, чем инвестировать в сотни кнопкодаво-часов, которые будут полгода всё обмазывать своими автоматическими технологиями доказательсва корректности всех веток кода на всех данных, а потом потерять бизнес вообще по другой причине.

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

Короче, краткий ответ: НЕНУЖНО, потому что не бесплатно.



Последнее исправление: lesopilorama (всего исправлений: 5)
Ответ на: комментарий от Chiffchaff

И вот когда покрытие тестами близко к 100%, комфорт от работы намного выше, потому что уже знаешь из опыта, что если тесты прошли успешно, то после выкатки на прод проблем скорее всего не будет.

Да. А потом натравливаешь какую-нибудь PVS-Studio, и она так ругается, так ругается… ;)

tiinn ★★★★★
()
Ответ на: комментарий от Stanson

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

Полное покрытие, упоминавшееся в треде, это полное покрытие кода тестами, а не то, что вы с @firkax подумали) Т.е. определяется, какие строчки кода выполняются при выполнении тестов (автоматом, при помощи дебаггера), потом это делится на общее количество строк кода, и получают допустим покрытие в 80%. И пока вы не начали опять что-то ассумить, 100% покрытие не гарантирует 100% корректности, но когда у тебя покрытие 15%, или растет или падает, какие-то выводы все же можно сделать)

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от goingUp

Полное покрытие, упоминавшееся в треде, это полное покрытие кода тестами

Бгг. :) Похер что там и насколько правильно считается, зато «полное покрытие кода тестами».

Как показывает практика, внедрение всевозможейших «панацей» от всяких растов до вот этих «покрытий тестами» неизбежно приводит к падению качества кода.

И аргументы апологеты этих панацей приводят совершенно идентичные:

100% покрытие не гарантирует 100% корректности, но когда у тебя покрытие 15%…

А потом у них синусы принимают значения вплоть до 1e38, или валидность FQDN определяется по наличию хотя бы одной точки в строке. Зато «безопасно» и/или «покрыто». А то что в итоге получается говно - так это не они, у них всё «безопасно» и «покрыто» же, а «насралося» оно само, ага.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson
  1. Нужно нормально писать софт
  2. Если софт некорректно работает, см. п. 1

Это гениально! Жаль только что нефальсифицируемо) Но, как известно, не все истины фальсифицируемые)

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)

предварительная оптимизация

Ты, для начала, поди перечитай, о какой предварительной и какой оптимизации писал первоисточник. А уж опосля вдумчиво применяй этот термин.

Цена тестов и кодревью оправдана, когда у тебя CI/CD настроено и все четенько плывет по накатанной от тебя до прода.

и дадут ли потом время переделать

Конечно дадут. Чай не идиоты там сидят. А ты — греби своим веслом и не квакай.

краткий ответ: НЕНУЖНО

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

deep-purple ★★★★★
()
Ответ на: комментарий от goingUp

Да-да, «насралося».

Что там с фальсифицируемостью тестов?

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

А если это автомат состояний, с сотнями параметров и условий и, соответственно какими-ниубдь квинтиллионами возможных состояний - то чем вообще поможет парочка сраных тестов, кроме создания ложной увернности у долбодятла (и его начальства), который уверовал в «полное покрытие», в том что всё правильно?

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

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

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

Есть только черный и белый цвет, без оттенков?

u-235
()
Ответ на: комментарий от u-235

Есть только черный и белый цвет, без оттенков?

Да-да, конечно-конечно, при определённых условиях значение синуса может колебаться от 7 до 9, а «покрытие тестами» означать не проверку правильности всех возможных вариантов, а что-то совсем другое. Ну и 157 «гендеров» тут тоже где-то рядом.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Как показывает практика, внедрение всевозможейших «панацей» от всяких растов до вот этих «покрытий тестами» неизбежно приводит к падению качества кода

Открою секрет. Тестируемость кода один из главных показателей его качества (я не помню есть ли у Мартина). Например если смешать доменную логику и какую-то интеграцию/мидлварь или наоборот не разделять на модули/классы, то это сразу нарушит пачку известных паттернов, а вместе с тем и нормальный тест будет занимать овердохрена времени и приседаний.

Lordwind ★★★★★
()
Ответ на: комментарий от Lordwind

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

Если качество кода оценивать по количеству успешно пройденных тестов - то да, тестируемость будет офигенным показателем такого «качества». И начальству можно красивое показать, и жопа прикрыта, если что.

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

Stanson ★★★★★
()

Короче, краткий ответ: НЕНУЖНО, потому что не бесплатно.

Дай, угадаю, ты никогда не писал того что надо поддерживать больше года?

bdrbt
()
Ответ на: комментарий от bdrbt

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

masa ★★★
()
Ответ на: комментарий от Stanson

качество кода оценивать по количеству успешно пройденных тестов

тестируемость и качество это не то что ты сейчас нафантазировал

Lordwind ★★★★★
()
Ответ на: комментарий от Lordwind

тестируемость и качество это не то что ты сейчас нафантазировал

Ваша «тестируемость» и ваше «качество» - вообще не ничем не являются. Бессмысленное пустое место не имеющее абсолютно никакого смысла кроме решения всяких внутрикопроративных галеропроблем.

Stanson ★★★★★
()
Ответ на: комментарий от masa

Или то что разрабатывает несколько человек.

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

bdrbt
()
Ответ на: комментарий от Zhbert

не очевидно?

Недавно знакомый PM спрашивал совета в духе «как объяснить разработчикам что нужно писать тесты». А поскольку PM трудился в аутсорсе, где средняя длительность проекта 6-9 мес, то я ответил «никак». Банально конечно, но слова ничего не изменят для тех, у кого нет потребности, а у кого есть, тем и так все очевидно.

Lordwind ★★★★★
()
Ответ на: комментарий от Stanson

Ваша «тестируемость» и ваше «качество» - вообще не ничем не являются.

Тестируемость всегда является одним из критерием качества. Тесты пишут совсем не для начальства или «галеры».

bdrbt
()
Ответ на: комментарий от Zhbert

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

Lordwind ★★★★★
()
Ответ на: комментарий от Stanson

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

А если это автомат состояний, с сотнями параметров и условий и, соответственно какими-ниубдь квинтиллионами возможных состояний - то чем вообще поможет парочка сраных тестов, кроме создания ложной увернности у долбодятла (и его начальства), который уверовал в «полное покрытие», в том что всё правильно?

Стансон, это невероятно, вы пишете настолько сложные программы, что даже не понятно, правильно или нет они работают! Ну круто же. Чесно говоря в первый раз такое вижу)

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

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от Zhbert

*поставил себя на место людей, ни разу не сталкивавшимся с тестами*

Не, не очевидно, какая-то неявная сущность, на которую надо тратить много времени

Dimez ★★★★★
()
Ответ на: комментарий от Dimez

Там вопрос был про очевидность, что ТС ничего серьезного не писал :)

Zhbert ★★★★★
()

Бизнесу дешевле полдня полежать

Так-то. Понимание задач бизнеса

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

flant ★★★★
()
Ответ на: комментарий от goingUp

Стансон, это невероятно, вы пишете настолько сложные программы, что даже не понятно, правильно или нет они работают!

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

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

Да и как «покрытие тестами» вообще может помочь найти ошибку проявляющуюся только в реальном мире?

По моему скромному опыту как раз тесты в более сложных местах дают больше профита, так как там хуже видно умозрительно, правильно ли написан код

Ну и как же написать полноценный тест хотя бы для sin(x)? И да, это при учёте того, что образцовой реализации этого условного sin(x) вообще не существует. Можно только в реальном мире палку покрутить и потом линеечкой с угольником померить и сравнить измеренное с посчитанным.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Ну и как же написать полноценный тест хотя бы для sin(x)?

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

Если реальные спектры реальных красок сделанных по рассчитанным рецептурам совпадают со спектрами образцов, рецептуры которых надо было рассчитать - то, значит, считается всё правильно.

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

goingUp ★★★★★
()
Ответ на: комментарий от Stanson

Да и как «покрытие тестами» вообще может помочь найти ошибку проявляющуюся только в реальном мире?

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

Lordwind ★★★★★
()
Ответ на: комментарий от firkax

Ты не поверишь… я нашел баг. Мне тут иногда мои куски кода скармливают чатуГпт, есть у человека доступ к нему. Так вот, одну функцию, точнее небольшой класс мой перереботали чатГпт. Да так красиво, правдоподобно. Ну я и взял код. Баг оказался в нем.

Там хитрая рекурсия, накапливала несуществующие фреймы.

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

Так что ты был абсолютно прав по сути. Толко это был небольшой класс на пару десятков строк, а не 2,5 тыщи. Но так хитро все было, что три недели искал его. Нашел по наитию чисто случайно. Обнулил его и фпс восстановились.

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

LightDiver ★★★★★
()
Последнее исправление: LightDiver (всего исправлений: 1)
Ответ на: комментарий от Stanson

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

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

чем вообще поможет парочка сраных тестов,

Их там не парочка будет. В норме юнит-тестов должно быть пропорционально количеству классов и методов. Если добиваться хорошего покрытия, то объем кода с тестами будет превышать объем «боевого» кода.

Поможет тем, что чем на более ранней стадии разработки выявляется дефект, тем меньший экономический ущерб он наносит.

кроме создания ложной увернности у долбодятла (и его начальства), который уверовал в «полное покрытие», в том что всё правильно

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

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

чистая профанация ради прикрытия своей жопы - «а я чо, все тесты были пройдены, я ничо, насралося.»

Спрашивают за результат (процент времени простоя сервиса, количество серьезных инцидентов вроде потери данных, и подобные метрики). Мычание о том, каким образом ты этого результата достиг (или не достиг) на судьбу задницы не особо влияет.

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

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 2)
Ответ на: комментарий от goingUp

«Полноценный» в смысле проверить его в каждой возможной точке? Но IRL ты его же тоже не проверяешь в каждой точке.

Это я к тому что тесты вообще ничего не говорят о качестве кода. Только то, что код в конкретных условиях и с конкртеными ввходными данными делает то, что ожидается в этом конкретном случае, но никак не больше.

Для кода sin(x) тесты бессмысленны. Его надо либо доказывать, либо надеятся на багтрекер. Протестировать его невозможно.

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

Ага. И типа успокаивать себя, что всё хорошо. А потом, на другом наборе пигментов и другом связующем окажется что всё через жопу и там баги со слона размером.

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от Manhunt

Сложный автомат должен быть декомпозирован на простые части, каждая часть протестирована по отдельности

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

даже хорошее покрытие тестами само по себе не даёт никаких гарантий.

Да. А ещё тесты не всегда и везде применимы, а иногда от них ущерба больше чем предполагаемой пользы. Поэтому «полное покрытие тестами» в большинстве случаев просто не имеет смысла. Тестами надо покрывать только те части кода, что можно покрыть тестами. И тесты, по-уму, писать должен не автор кода, а другой человек.

Тесты - это производственная практика, это инструмент разработки.

Практика - да. Инструмент разработки - не особо. Дофигища отличных проектов создано без каких-либо тестов, и багов там не больше чем в софте с максимальным покрытием тестами.

И это точно не панацея и не замена головы.

Если бы это ещё было написано огромными буквами в каждой статейке и учебнике где упоминаются тесты. Причём два раза. В начале и в конце материала.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

при определённых условиях значение синуса может колебаться от 7 до 9

А что, тебе, с высоты твоего развития, кажется, что не может?

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

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

Для тестового покрытия широко приняты разные метрики. Например:

  • function coverage - процент функций, которые хотя бы раз были вызваны хотя бы одним из тестов;
  • line coverage - процент строк исходного кода, которые были задействованы хотя бы одним из тестов;
  • branch coverage - процент линейных участков кода, которые были задействованы хотя бы одним из тестов;


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

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

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

К сожалению, как и всё в этом мире, тесты не только приносят пользу, но и имеют цену — их надо писать и (что особенно важно) поддерживать в актуальном состоянии.

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

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)
Ответ на: комментарий от Stanson

Сложный автомат должен быть декомпозирован на простые части, каждая часть протестирована по отдельности

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

"Как всё соединено" отлично тестируется посредством dependency injection и mock-ов. При условии, что была выполнена адекватная декомпозиция (low coupling and high cohesion).

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

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

Кроме того, привлечение другого сотрудника автоматом влечёт затраты на оформление багов в багтрекере, затраты времени ещё и менеджера на управление багами в багтрекере (приоретизация, отслеживание, и тд), затраты на коммуникации между тестировщиком и разработчиком (и тут оказывается, что надо интровертов-аутистов увольнять нахер, и нанимать ребят с хорошими soft skills, чтобы они могли друг с другом коммуницировать). Собственно, внедрение юнит-тестирования позволяет заметно снизить возню коллектива с багами (многие баги тупо не доживают до других сотрудников).

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 6)
Ответ на: комментарий от Nervous

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

Это хреновая кодовая база (плохо структурирована) и хреновые тесты (когда добивались покрытия, не рефакторили тестируемый код, а просто херачили «на скорость»). Согласен, что так жизни не будет.

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

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

Stanson ★★★★★
()
Ответ на: комментарий от Manhunt

«Как всё соединено» отлично тестируется посредством dependency injection и mock-ов. При условии, что была выполнена адекватная декомпозиция (low coupling and high cohesion).

Представь себе сложную схему из сотен логических элементов И-НЕ. С сотнями входов и десятками выходов. При этом некоторые выходы соединены с некоторыми входами.

Или усилитель/преобразователь/смеситель и т.п. с обратными связями.

И как же предполагается это декомпозировать?

Юнит-тесты должен писать именно автор кода.

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

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

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

При непосредственном тестировании гораздо легче обеспечить полноту покрытия, и тем самым создать условия для проявления бага. А тесты клиентской функции (т.е. функции, которая пользуется данной) тогда могут быть сфокусированы на покрытии кода именно самой клиентской функции, а не на опосредованном покрытии кода её зависимостей. Вполне вероятно, что клиентскую функцию захочется тестировать не с «боевыми» зависимостями, а с моками. То есть, смысл - в снижении сложности тестов, по принципу "разделяий и властвуй".

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

Представь себе сложную схему из сотен логических элементов И-НЕ. С сотнями входов и десятками выходов. При этом некоторые выходы соединены с некоторыми входами. И как же предполагается это декомпозировать?

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

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

Да замыленность тут не особо мешает. В тесткейсе ты фиксируешь некие эталонные данные и эталонный результат, который должен получаться на этих данных (надо честно сформировать данные и результат своим умом, не запуская код). Затем запускаешь тест, и тем самым проверяешь, что твой код работает в соответствии с тем, как ты считал правильным. Для формирования эталонных данных есть методика: проверить предельные случаи (числовые параметры - очень большие и очень маленькие, списковые параметры - пустые и максимально длинные, и тд), проверить точки в которых логика должна переключаться между разными вариантами поведения, а также оставить в тесте пример типичных данных (какие по замыслу и должны бы в основном обрабатываться этим модулем). А дальше тебе подскажет анализ покрытия - какие ещё участки кода совсем не проверены, и надо будет дописать тесткейсов для них тоже. Вот и всё.

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 2)
Ответ на: комментарий от Lordwind

Да, конечно, во всём должен быть баланс и присутствие головы.

Но даже

Я сам отдаю максимум 80% кода им, это юниты и контрактные, выше схема ломается

это очень хорошо. Сильно развязывает руки.

mono ★★★★★
()
Ответ на: комментарий от Manhunt

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

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

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

Это будет работать только для какой-то элементарщины. Как только появляется неопределённость, обратная связь, рекурсия и т.п. вся эта красивая картина превращается в бесполезную кучу хлама. Даже элементарный тест UI мордочки с сотней разных контролов - это в разы больше кода при отсутствии каких-либо гарантий, а значит и пользы. Сколько не пиши тестов, пользователь всегда умудрится сделать с минимально сложным интерфейсом какую-то дичь. Здесь как раз есть насущная необходимость в покрытии тестами, потому что хрен добьёшься от пользователя конкретной последовательности действий приводящей к глюку UI, чтобы воспроизвести в лабораторных условиях. Однако, как раз то, что стоило бы обложить тестами, обложить тестами совершенно нереально за разумное время и средства.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

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

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

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

Про элементарщину уже обсудили выше - декомпозиция наше всё.

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

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

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

Даже элементарный тест UI мордочки с сотней разных контролов

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

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 3)
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)