Наверное, многим очевидное, но приходит со временем:
тесты тоже очень легко написать так, чтобы они подтверждали твою собственную ошибку.
Ты уже знаешь, как система «должна» работать.
Пишешь код из этой модели.
Потом из этой же модели пишешь тест.
Создаёшь нужное состояние. Делаешь нужные шаги. Проверяешь ожидаемый результат.
Зелёное.
Ну охуенно :D
Только иногда это не два независимых доказательства.
Это две реализации одной и той же мысли, которые согласились друг с другом.
И чем дольше ковыряю распределённые системы, тем больше мне это не нравится.
Потому что тест вообще может незаметно сделать за продукт часть работы: создать состояние, которое в реальности никто не создаёт; положить данные, которым неоткуда взяться; вызвать переход, исполнителя которого в настоящей системе нет.
Причём тест не врёт.
Он честно проверяет ровно тот мир, который ты ему построил.
Проблема в том, что этот мир придумал тоже ты.
Поэтому мне сейчас гораздо интереснее не «какие ещё тесты написать», а как заставить тесты спорить с моей моделью системы.
Не только воспроизвести штатный сценарий, а попробовать сделать заявленную гарантию ложной.
Убрать кусок механизма.
Потерять ответ.
Повторить одно действие несколько раз.
Поменять порядок событий.
Оставить систему надолго вообще без изменений.
И посмотреть, где мои красивые «значит» перестают быть правдой.
Наверное, отсюда у меня постепенно появился довольно простой критерий:
зелёный тест говорит, что система прошла придуманный тобой сценарий.
А хороший тест ещё должен ответить на более неприятный вопрос:
что именно должно сломаться, чтобы он перестал быть зелёным?
Если ответ — «ну, примерно то, что я уже предусмотрел», то, возможно, мы всё ещё тестируем собственную уверенность.
Post #47
27
