l3ftoverz
@l3ftoverz
Rings of Saturn - The Husk

Какие книги мне стоит прочитать для тестирования кода?

В целом, заголовок описывает суть моего вопроса. Никак не привязываюсь к языку, хочу вообще, прочитать что-то углублённое и общее на эту тему. Базовые вещи я знаю и понимание (как мне кажется) есть.

Но как бы то странно не звучало: я не тестирую сейчас свой код.
Что посоветуете прочитать? В идеале что бы после прочтения, желания писать код без тестов у меня не было вовсе.
  • Вопрос задан
  • 744 просмотра
Решения вопроса 3
Maksclub
@Maksclub
maksfedorov.ru
Кент Бек. Экстремальное программирование. Разработка через тестирование
В книге шаг за шагом показывают, как тестить. Приведены техники, также на 2х языках (Питон и Джава, но понятно будет и вам). Чувак помимо автора методики, еще и автор JUnit.
xUnit — это собирательное название семейства фреймворков для модульного тестирования, структура и функциональность которых основана на SUnit, предназначавшегося для языка программирования Smalltalk. SUnit, разработанный Кентом Беком в 1998 году,.


Хорошая глава (но небольшая) есть в "Чистом Коде" Роберта Мартина

В идеале что бы после прочтения, желания писать код без тестов у меня не было вовсе
А вот тут посоветую такое вот видео (заголовок пусть не смущает, потрясное):
Видео: Андрей Солнцев — Пацан накодил — пацан протестил!
Ответ написан
Alex_Wells
@Alex_Wells
PHP/TS/Kotlin developer
Мотивирующие что ли? Если да, то никакие. Желание писать тесты (ну или хотя бы вручную протестить, если авто тесты слишком запарно для какого-то супер-сложного кейса писать) появится само, когда вы десятки, сотни раз повторите одни и те же ошибки: ошибетесь и это попадет на продакшен; решите что-то тестануть, даже самое простое, а окажется, что оно работает совсем не так, как вы хотели; когда увидите, как кто-то сломал ваш код, а исправляете в спешке его вы.

Лично я не пишу тесты только если работаю в одиночку и нету времени, что бы их писать. В остальных случаях я пишу их в 95% случаев, потому что мне проще один раз написать тест, чем потом фиксить что-то, боятся трогать существующий код, проверять по триста раз вручную.
Ответ написан
У нас в компании есть несколько правил:

1) Задача не допускается к ревью, если там нет тестов, которые покрывают основную логику входа и выхода.
2) Максимально надо использовать юнит тесты, а не интеграционные (чтобы время выполнения всех тестов было меньше).
3) Тесты должны покрывать внешние аргументы, которые передаются в код (чтобы изменение внешних данных не ломало код).
4) Нужно использовать ТДД для задач, которые работают с существующим кодом (т..е например, какие-то продуктовые задачи, где все меняется - пишутся без тестов, потом покрываются тестами), а вот какой-то рефакторинг компонента отправки почты - пиши с ТДД.

__

p.s. в ряде компаний, например, есть специальный отдел, которые пишут тесты на код разработчиков.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы