LevT
Platinum Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Test-Driven Development перевод главки отсюда This is an in-progress chapter. Heres what we have left to do: Jeff hasnt completed his pass We havent done our final copyedit and tech edit Эта глава ещё пишется. Вот что нам ещё осталось сделать: Джефф не сказал свое слово, и мы не сделали финальную вычитку. Test-Driven Development, или TDD – большая философия. Test Driven Development by Example, by Ken Beck один из лучших текстов на эту тему, если захотите копнуть глубже… потому что мы сейчас глубже не полезем. В сухом остатке, TDD это всего лишь практика написания юнит тестов раньше написания самого кода. Ваши юнит тесты служат, таким образом, как бы подробной функциональной спецификацией для вашего кода. Если бы кто-то другой написал за вас код, было бы достаточно убедиться, что тот проходит все ваши тесты, и вы с ним согласились бы насчет того, что код хорош. Это не значит сидеть и писать все возможные тесты, которые могут вам потенциально понадобиться. На практике это означает, что TDD это часть итеративного процесса написания кода (за исключением самых простых однострочников). Допустим, к примеру, что вы обычно начинаете писать функцию с определения её параметров. Самое обычное дело. С TDD вы бы начали с написания тестов, которые проверяют и валидируют те параметры, прежде единой буквы реального кода. Вы бы писали тесты, которые проверяют работу трубы там, где та предполагается, а также тот факт, что принимаются все те наборы параметров, которые предполагаются, и т.п. После того, как тесты готовы – вы б начинали писать ваш код с параметров (как вы обычно и делаете, если следуете нашим рекомендациям). Вы б продолжали возиться с блоком Param до тех пор, пока все тесты не станут зелёными. Затем вы бы двинулись дальше, например, у вас есть параметр-переключатель, изменяющий поведение функции. Вы бы написали тесты, которые тестируют разные вариенты поведения, и только потом реализацию этой логики, и потом запустили свои тесты. И продолжали бы править свой код до тех пор, пока все тесты не позеленеют. Идея TDD - заставить вас думать о том, каким требованиям ваш код должен соответствовать прежде, чем вы рванётесь реально просиживать задницу в IDE. Первоочередное написание тестов предполагает определённую фазу дизайна, когда вы думаете о вещах прежде, чем начинаете печатать. TDD как бы заставляет вас делать то, что вы и так считаете полезным, но не всегда хотите делаеть. Допустим, вы закончили писать функцию (и её тесты!). Впоследствии обнаруживается баг. Прежде чем фиксить этот баг, вы пишете тест(ы) для обнаружения этого бага. Вначале этот тест провалится. Но потом вы начинаете фиксить ваш код до тех пор, пока все тесты не позеленеют вновь. С TDD всегда сначала пишется тест, а лишь затем код, проходящий этот тест. Это большой гимор. Поверьте, ещё не каждая команда профессионалов поступает так. Но те, кто это делают, весьма успешны благодаря этой методологии, пишут более полные и надежные наборы тестов-костыли(fixtures), способные поддержать сложные общие/групповые цели, которыми определяется желаемое поведение кода. | Всего записей: 17164 | Зарегистр. 14-10-2001 | Отправлено: 10:17 01-05-2018 | Исправлено: LevT, 15:19 01-05-2018 |
|