TDD каты
TDD — test driven development: сначала пишешь тест, затем код для него, а потом рефакторишь. Важно писать маленькими порциями: маленький шаг в тесте, код, который кратчайшим путём реализует тест. Так тестов будет много, они будут отражать реальное поведение кода.
Для себя я выделил три важных следствия:
1. Тесты разгружают голову. Можно сфокусироваться только на одном, не боясь сломать что-то.
2. Время на написание тестов не увеличило разработку, потому что я сэкономил на дебаге.
3. Протестированную систему не страшно рефакторить. Если что-то отпало — увидишь.
Звучит хорошо, но как перебить привычку писать код, а потом забивать на тесты? У нас принято новичкам давать «каты» — простые задачки, цель которых отработать TDD правила. Посчитать очки в боулинге, написать работу лифта или странное «рассчитать как водители сплетничают». Есть сайт с заданиями: http://kata-log.rocks/bowling-game-kata
TDD — test driven development: сначала пишешь тест, затем код для него, а потом рефакторишь. Важно писать маленькими порциями: маленький шаг в тесте, код, который кратчайшим путём реализует тест. Так тестов будет много, они будут отражать реальное поведение кода.
Для себя я выделил три важных следствия:
1. Тесты разгружают голову. Можно сфокусироваться только на одном, не боясь сломать что-то.
2. Время на написание тестов не увеличило разработку, потому что я сэкономил на дебаге.
3. Протестированную систему не страшно рефакторить. Если что-то отпало — увидишь.
Звучит хорошо, но как перебить привычку писать код, а потом забивать на тесты? У нас принято новичкам давать «каты» — простые задачки, цель которых отработать TDD правила. Посчитать очки в боулинге, написать работу лифта или странное «рассчитать как водители сплетничают». Есть сайт с заданиями: http://kata-log.rocks/bowling-game-kata