При чем здесь DLL?

Там про модули что-то.

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

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

Есть определенные философии модульного тестирования. Как правило Паретто. Например ты потратил 80% времени на написание кода, а 20% на сами тесты то это хорошая пропорция. Теперь за 1 милисекунду ты можешь проверить что твой проект "здоров". Это как метрика. Зелёная лампочка. Но поскольку ты говоришь про отладчик, я делаю вывод что ты не работал в коллективе и в крупной разработке. Потому что все обычно знают зачем нужны unit tests. Отладчик это уже шаг #2. Когда известно что ошибка существует.

Чтобы понять, есть ли ошибка - надо просто позапускать программу, и проверить её. А дальше отладчик. О каком "фреймворке модульного тестирования" речь? Что за придумки? 😂

А сколько времени у тебя уйдет на "позапускать" ?

В зависимости от сложности и размеров программы. В среднем, 10-30 минут. Хорошо, значит ты говоришь про скриптик, который тупо запускает программу, и имитирует действия пользователя - обычный скрипт на AutoIT, либо Python. Каким боком он тогда к языку программирования вообще привязан? 😂 Он должен просто запустить .exe, и проверить функционал, отправляя и генерируя тестовые значения. Так что всё это в ассемблере есть.

Слушай КТ. Ты классный чувак. Но у тебя есть привычка. Зайти на трибуну и колотя ботинком рассказывать что всем покажешь "кузькину мать". Я тебя прошу. Ты хоть новичкам не рассказывай вредных советов. А то тебя послушают и будут думать что сложный проект может существовать без тестов и без спецификации. Я тебя прошу.

Вообще-то может, это не вредные советы. Ты наслушался девопёсов, и теперь думаешь, что в каждый Hello World надо сувать какие-то тесты, спецификации, документацию на миллиард страниц и прочую ересь. TurboDebugger и миллион стабильного софта было написано только так - код, и отладчик. Точка.

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

Так это каких масштабов должна быть программа? Примерно как Firefox, PyCharm, Sony Vegas, IDA Pro и др. - 100 миллион строк кода. Тогда да, очевидно, нужна автоматизации в тестировании. Но для какого-нибудь отладчика типа x64dbg, OllyDbg, CheatEngine, анализатора DetectItEngine, CFF Explorer - это вообще ни к чему!

Как же трудно с тобой. Вы с Фроловым обсудили вероятность возникновения ошибки. Я добавил что необходимо тест. Чтоб доказать что код верный. Понимаешь? Автоматизация. Это так принято. Это критерии надёжности софта.

Стикер

Да ради бога. Развеж я буду настаивать. Пиши с дебаггером.

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

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

Тесты доказывают что данный тест кейс (или бизнес кейс) работает в полном соответствии со спецификацией. Вот и все.

Только если ты тестируешь всё множество входных параметров. Что, очевидно, невозможно. Ну условно mkdir("x") ничего не доказывает про mkdir("x" * 10000).

Если ты не знаешь как тестировать I/O то спроси меня.

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

Это не про IO. Это про множества. Тестируют обычно тривиальные случаи, и то, что считают граничными случаями. Но всегда могут быть другие граничные случаи, которые ты упускаешь.

Ты вроде рассказывал что работал в проекте где 50 человек было. Это правда?

Где я такое говорил?

Я не знаю ни одной функции которую я не смог бы протестировать автоматически. Разумеется мы должны понимать что мы разработали а какая спецификация.

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

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

А вот я про фаззинг говорил. Генерировать данные, и флудить ими в программу. Полезная штука. А юнит-тесты это что тогда?

Это assert(cos(0.0) == 1.0) (ухмыляющийся смайлик).

Ааааа, теперь понял. Да, такого в ассемблере нет. Только это бесполезная штука всё же.

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

И всё же интересно, ты работаешь программистом?))

Bio же. Я программист хелловорлдов, кому я нужен?

Да не поверю. Ну, ладно, скромняга.

Property -based testing. Это когда тебе надо доказать, что написанная тобой функция ведёт себя одинаково на любом инпуте. PBT используется при тестировании архиваторов, енкодеров. Типа dec(enc(msg))==msg.

Что-то очень научное.

Нет. Просто методика тестирования.

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

Какая наигранная скромность.

Вот здесь я находил https://jqwik.net/property-based-testing.html

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