Ну, пока это что-то типа мутационного тестирования для меня)

Прикольно, но зачем это в жсе непонятно

https://github.com/typeetfunc/csssr.github.io/blob/master/_posts/2016-11-10-property-testing.md - читал?(да я опять пиарюсь) на самом деле можешь не читать но глянь там в конце ссылки - там очень хорошо кейсы описаны

Ну например что б быть уверенным в том, что твой метод работает корректно СО ВСЕМИ возможными входными значениями, а не только с теми, что ты явно прописал в тесте

https://github.com/typeetfunc/csssr.github.io/blob/master/_posts/2016-11-10-property-testing.md - читал?(да я опять пиарюсь) на самом деле можешь не читать но глянь там в конце ссылки - там очень хорошо кейсы описаны

Ты мне в фронтэнд слэке и скидывал вроде)

Front-end Belarus который

а точн) я и думаю что аватарка знакомая)

Ага, я только по статье и понял, что это ты)

У тебя ваще аватарки нет:/

Ладно, гляну еще раз чтобы осаежить память

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

Опа, клёво, мне вот как раз сейчас требуется

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

Пример конечно не оч про сумму)

Пример конечно не оч про сумму)

Я тебя наверное не очень понимаю. Для каких случаев у тебя такой тип тестирования может вообще не подойти?

да для всего сложнее сложения уже начинаются проблемы

надо же найти свойство какое то

у нас большая часть кода имеет сайд-эффекты и прочее неопределенное поведение - там очень тяжело искать свойства

да для всего сложнее сложения уже начинаются проблемы

Для любых чистых функций идеально

пока самое подходящее это тестить так преобразования стейта(в редаксе и подобном) - как у меня в статье или как тут https://github.com/omcljs/om/wiki/Applying-Property-Based-Testing-to-User-Interfaces

ну и много у нас сейчас "больших" чистых функций?

у нас большая часть кода имеет сайд-эффекты и прочее неопределенное поведение - там очень тяжело искать свойства

Код с обилием сайд-эффектов - плохой код. Но это поддается рефакторингу

++

как?

Как угодно, мы же не знаем архитектуры и степени запущенности проекта

setState dispatch это сайд-эффекты если чо

ну и много у нас сейчас "больших" чистых функций?

Они не должны быть большими

Я тебя наверное не очень понимаю. Для каких случаев у тебя такой тип тестирования может вообще не подойти?

Ты в сложении не описываешь инварианты

Код с обилием сайд-эффектов - плохой код. Но это поддается рефакторингу

Вообще-то нет, если у вас нет спецэффектов, то ваш код ничего не делает)

++

Сайдэффектов *

и я знаю способы абстракции IO (аж 3 штуки) но только их никто не использует же

Никто не пишет код на хаскеле?))

Еее спецэффекты

setState dispatch это сайд-эффекты если чо

Тебе достаточно проверить что setState вызывался и с такими-то параметрами

Еее спецэффекты

:Р

Это же касается любого сайд-эффекта

Проблема в том, что тогда этот тест не очень нужен

Ты в сложении не описываешь инварианты

Я плох в терминах ) Что такое инварианты?

К одному и тому же сайдэффекту можно придти совсем разными путями

>Никто не пишет код на хаскеле?)) даже если и пишет то об этом никто не знает и на мейнстрим это никак не влияет)

Я плох в терминах ) Что такое инварианты?

Свойства твоих объектов, которые всегда выполняются

Например связь push и length в массиве

Это инвариант объекта

Есть ещё инварианты цикла — условия на время итерации

хз о чём именно вы тут, я не читал

О первом я

К одному и тому же сайдэффекту можно придти совсем разными путями

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

Например связь push и length в массиве

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

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

Я подумаю над разницей

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

То что она была вызвана оч вероятно, что деталь реализации

Свойства твоих объектов, которые всегда выполняются

Ты это можешь проверить как это обычно делают в TDD - тест сперва обязан упасть

вот я писал о проблемах тестов сайд-эффектов https://github.com/typeetfunc/csssr.github.io/blob/feature/effects/_posts/2016-12-16-side-effects-1.md#cайд-эффекты-сложно-тестировать

основная проблема в том что нет предопределенной функции проверки сайд-эффекта

то есть для первоклассного значения ты просто делаешь .toEqual

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

и эта проверка будет устаревать

ты ее можешь не правильно придумать

и так далее

в общем случае сайд-эффект меняет мир

и после теста надо бы сравнить мир до и мир после

я чот не знаю такой функции

expect(global).to

:)

Шутка

Я не гуру тестов ) Но думаю что для поклонников TDD делать надо так - сперва пишутся атомарные тесты для коротких итераций разработки. И в конце, когда требуемая функциональность полностью написана, она покрывается property-based тестами. Просто для того что б убедиться что все работает с ЛЮБЫМИ допустимыми входными значениями.

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

и зачастую его можно заменить типизацией

есть куча других свойств

типо идемподентности

и их тоже хочется проверять

http://fsharpforfunandprofit.com/posts/property-based-testing-2/

Не заменишь типизацией. Надо проверить например что С ЛЮБЫМИ числами этот метод работает

Не заменишь типизацией. Надо проверить например что С ЛЮБЫМИ числами этот метод работает

С любыиюми просто в типах, сложно если например только с четными)

Потому что ошибка может проявиться, скажем, при случаях когда один параметр больше другого

Да, или на чётных

я и не сказал что всегда. для этого есть всякие навороченные системы типов - refinement итд ошибка - это когда падает или когда неверный результат?

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

Так падение это тоже результат

если ты в тесте будешь воспроизводить вычисления то как бы это не очень тест

это иногда имеет смысл и называется test oracle

но очень не всегда

Ну собственно это в примере с плюсом и было

Но есть еще обратимые операции ж

С ними тоже удобно)

да с обратными проще - и это тоже одно из свойств

There and back again

в той статье что я кинул

обычно это сериализация десериализация

но это все очень простые свойства я уверен что мы могли бы увидеть намного больше если бы наше ПО было более предсказуемым и "математичным" :)

У нас работы не было бы)

Была бы

Просто гораздо выше уровнем

Больше продукта, меньше железа

ну я лучше буду без работы чем меня убьет какая нить рентген установка изза глобальных переменных xDD

и после теста надо бы сравнить мир до и мир после

мОкать надо такие вещи

ну я лучше буду без работы чем меня убьет какая нить рентген установка изза глобальных переменных xDD

Ну одно требует такого подхода, а очередной инстаграм нет

ну возможно что очередной инстаграмм вообще не стоит делать и тратить на это деньги

ну возможно что очередной инстаграмм вообще не стоит делать и тратить на это деньги

Делают потоиу что покупают)

но тут уже вопрос политически социальный ага а не программисткий)

так что out of scope)