Почему большинство юнит тестов — пустая трата времени? (перевод статьи)

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

Отсюда можно сделать и выводы:
— Спасибо Джеймс за ваше мнение, но выводы мы сделаем сами.

Давайте на хорошо написанные юнит-тесты:

#[pure]
#[ensures(result >= a && result >= b)]
#[ensures(result == a || result == b)]
fn max(a: i32, b: i32) -> i32 {
    if a > b {
        a
    } else {
        b
    }
}

#[ensures(result == max(a, max(b, c)))]
fn max3(a: i32, b: i32, c: i32) -> i32 {
    if a > b && a > c {
        a
    } else {
        if b > c {
            b
        } else {
            c
        }
    }
}

Обратите внимание, что результатом выполнения этих юнит-тестов является полное покрытие не только всего кода, но и всех множеств входных значений, т.е. эти юнит-тесты (для функции max3) покрывают все возможные 79228162514264337593543950336 вариантов входных значений.

Вот это — хорошо написанный юнит-тест.

Для заинтересовавшихся: https://viperproject.github.io/prusti-dev/user-guide/intro.html

Имхо, редко встретишь работающие юнит-тесты, после того как программист написавший их покинул проект.

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

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

Я давно заметил, что настоящего ООП в моих проектах мало осталось. И не в последнюю очередь из-за юнит-тестов. Классы чаще сборище публичных методов, что бы проще было тестировать. А Service-, Repository-Классы (java, spring) обязательно чрез интерфейсы, что бы удобнее было их мокать в юнит-тестах. Больше эти интерфейсы собственно нигде и не используются в коде, кроме как в папке test.

Так что test driven design можно сказать победил, по крайней мере в проектах где я сижу.

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

Это в какиеж такие времена? Когда я лично писал на фортране (а это было в 70-х и 80-х годах прошлого века), даже понятие юнит тестов еще не оформилось. Насколько я помню они стали популярны как раз после появления XP и книжки Бека, т.е. где-то самый конец 90-х. Fortran же, если на то пошло, появился в 1957.

Большие функции, для которых 80% покрытие было невозможным, разбивались на множество более мелких, для которых 80% уже было тривиальным. Такой подход повысил общий корпоративный показатель зрелости команд всего лишь за один год, потому как вы обязательно получаете то, что поощряете.

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

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

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

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

Вопрос: “Много ли информации содержится в этом тесте?” Другими словами, если “1” — это успешно выполненный тест, а “0” — упавший, тогда сколько будет информации в следующей строке результатов:
11111111111111111111111111111111
Существует несколько возможных ответов, обусловленных видом применяемого формализма, хотя большинство из них не верны. Наивный ответ — 32, однако, это биты данных, а не информации

По формуле Хартли 32, а как нужно подсчитывать?

Если вероятность успешного прохождения теста равняется 100%, тогда, по определению теории информации, этой информации нет вообще.

Но ведь она равняется 50%, а не 100%.

Ага, развели тут классы и полиморфизм какой-то… Интерфейсы напридумывали… Назад к ФП и Фортрану! ;)
А если серьезно — то я не представляю как можно писать без юнит-тестов.

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

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