другая мысль
Ну то есть понятно что не надо новичков путать философскими рассуждениями
Но что есть юнит-тест?
1) быстро выполняется (чтобы был быстрый фидбек)
2) проверяет небольшой кусок функциональности
3) должен сломаться если поведение сломано (или поменялось)
Например есть вот такая функция
function foo(arg1) {
if (typeof arg1 === 'string')
throw new Error('arg1 must be string')
// do smth
}
Ну и мы её тестируем
test(expect => {
expect.ToThrow(() => foo(1))
}
По сути то же самое можно выразить и в типах и все условия соблюдаются, фидбек будет быстрее, функциональность та же (с оговоркой), прекрасно сломается (причем еще в редакторе)
Понятно что пример немного вырожденный, но такое можно положить и на всякие null -проверки (strictNullChecks)
Получается типами мы можем выразить некий сабсет контрактного программирования (https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D1%82%D1%80%D0%B0%D0%BA%D1%82%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5), то бишь предусловия и постусловия на тип
При этом фидбэк у нас прямо в редакторе (быстрее и удобнее), писать меньше и еще всякие плюшки типа code completion и quick fix
С оговоркой потому что typescript не умеет в нормальную валидацию в рантайме и получается что это не идеально тоже самое
Получается что типами мы пытаемся описать контракты, а тестами проверяем само поведение
Да, в принципе верно - типы и тесты это контракты
Обсуждают сегодня