Comments 28
Какова вероятность, что три рандома подряд выдадут вам 3 нуля? Для 64-битного числа это будет 1/2**63**3 = 1/7e56
. Если взять суперкомпьютер ближайшего будущего на 7 эксафлопс, то матожидание выпадения джекпота из [ 0 , 0 , 0 ]
будет 1e38
секунд или 1e30
лет.
Но тут даже не настоящий рандом, а псевдорандом, где следующее значение является функцией от предыдущего, а это значит, что выдаёт он два одинаковых значения подряд примерно никогда.
Я могу ошибаться, но думаю что либы по property-test-ы к случайным значениям ещё и явно примешивают всякие базовые пограничные значения. Скажем эмоджи, какие-нибудь особо хитрые utf8 штуки (вроде буквы Ё в mac os), нули, предельные числа, дроби и пр.
То есть некоторого предустановленного набора граничных условий хватит всем?
function( a , b ) {
return 1 / ( a * b - 42 )
}
Через сколько итераций QuickCheck найдёт проблемные значения?
Вероятно не найдёт вообще. Но вроде как никто и не позиционирует это как серебрянную пулю. Все особые случаи, которые автор теста сам смог увидеть/заметить/вспомнить/понять, надо записать явным традиционным образом, а не надеяться на то, что random всё выведет.
Ну а на чуть менее очевидных случаях, как мы видим выше, рандом уже бесполезен.
Есть подобное, правда не совсем для property based testing, но близко — guided fuzzing, довольно популярный инструмент из этой категории — AFL. Изначально делался под C/C++, но его можно прикрутить и к другим языкам, например к питону (вот тут в третьей части это довольно неплохо описывается — а первые две посвящены как раз property based testing и генераторам тестовых данных для них, так что тоже может быть интересно)
Это уже статический анализ получается. Но в мире js с ним будет сложно, потому что всё может зависеть от контекста исполнения множеством самых разных способов
Не скажу за JSVerify, но в Erlang сделано именно так.
Например вот: https://habr.com/ru/post/434008/
Ну и на самом деле я бы сказал первоисточник подобных статей: https://fsharpforfunandprofit.com/posts/property-based-testing-2
Ничего нового тут не придумать, учитывая то, что они начали практиковать property-тесты намного раньше.
Мне казалось тесты должны удовлетворять условии детерминированности, чтобы можно было определить условие при котором возникает ошибка и заново его воспроизвести, то есть в них не должно быть date или random историй
P.S. Ссылки на видео с докладов лучше приложить в самое начало.
Property-based тестирование для JavaScript и UI: необычный подход к автоматизированным тестам