Шутки в сторону. Я тоже там был.

Как участник Github Open Source, мне всегда было трудно делиться контентом, который мог бы ясно объяснить определенные концепции и основы. Я всегда обнаруживал, что повторяю одно и то же снова и снова в комментариях Github и на рабочем месте.

Это одна из причин, по которой я начал писать: создавать открытый контент, который я могу использовать для обмена и распространения знаний. Чтобы иметь что-то, что я могу использовать, чтобы указать кому-то в правильном направлении.

Разработка через тестирование - одна из тех основ, которые разработчики очень неправильно понимают. Большинство постов говорят об этом только поверхностно. Редко есть что-то, что затрагивает эту тему.

Я хочу это изменить.

За последние несколько недель я написал серию сообщений, чтобы показать Первые принципы TDD с использованием JavaScript.

Вот их краткое описание (нажмите на заголовок, чтобы узнать подробности):

Недостающий практический шаг за шагом TDD

Этот пост начинается с истории Джека, ростовщика. Джек нанимает разработчика и ставит крайний срок завершения работы. Однако из-за TDD разработчику удается получить работающее программное обеспечение за долю времени, которое потребовалось бы для разработки всей спецификации.

В этом посте также показано, почему вам нужны небольшие тесты вместо одного теста, который побуждает вас реализовать все это.

Создайте один тест и напишите максимально простой код, чтобы он прошел. Не создавайте один тест, а затем пишите все.

Как создать тип данных Money в JavaScript

Этот пост решает проблему использования типа JavaScript Number для представления долларов и центов. Если вы не знаете о проблемах с арифметикой с плавающей запятой, вы обнаружите проблему использования типа JavaScript Number для представления денег только тогда, когда он не работает в производственной среде.

Проверьте то, что вы знаете. Вы не можете проверить то, чего не знаете.

Код, который вы пишете, должен быть хуже, чем предыдущий

В этом посте описываются уроки, которые я извлек при разработке этой серии TDD. Это также показывает, что не стоит ожидать получения хорошего кода при первой попытке решения проблемы. TDD способствует Постоянному совершенствованию; код становится только лучше с практикой.

Нет никакой серебряной пули, код, который вы пишете, становится лучше с практикой.

Это единственное, о чем вам никто не говорил о TDD

Этот пост показывает, что TDD - это не тесты; это о вождении. Вы пишете один небольшой тест за другим, каждый тест заставляет вас делать код более универсальным.

Кроме того, если вы следуете основам TDD, вам не нужно связывать неудачный тест из тестовой среды с «красной фазой» или успешный тест с «зеленой фазой». Вы можете практиковать TDD на другом уровне, где сообщение об ошибке синтаксиса представляет «красную фазу», а исправление представляет «зеленую фазу». Пока и первое, и второе сообщения предсказуемы, не имеет значения, какой инструмент вы используете для их просмотра.

Здесь важно то, что вы изменяете код только после получения отрицательной обратной связи от его запуска, независимо от того, какой инструмент вы используете.

Вы можете изменить только тот код, который вы можете запустить.

Как TDD может предотвратить чрезмерное проектирование

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

Если вы всегда создаете тест для обоснования написанного кода, то вам никогда не придется беспокоиться о написании кода, который вам не нужен.

Что побудило меня написать эту серию, так это общее непонимание значения разработки через тестирование в рабочем процессе программирования.

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

Кто-то из нас может чему-то научиться.

TDD позволяет понять проблему и создать хороший продукт для людей, а не писать код для прохождения тестов.

Почему ростовщик? Почему бы не использовать что-нибудь еще в качестве примера?

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

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

Я написал о ростовщике, чтобы вы могли прочитать этот пост и сделать вид, что вы работаете в неэтичной среде. Таким образом, вам не нужно работать на одного в реальной жизни и при этом получать опыт.

Делайте вид, что работаете в неэтичных проектах, чтобы вам не приходилось работать с тем, где вы можете нанести реальный вред

Задача программирования для Джека, ростовщика возникла в ходе собеседования, которое я провел для компании. В том случае, когда я проходил через дверь, я не знал деталей проблемы или решения. Вместо домашнего упражнения они дали возможность заниматься парным программированием, когда я выступал в качестве навигатора. Эта возможность позволила мне продемонстрировать ценность TDD, задать правильные вопросы и быстро решить проблему.

После собеседования они поняли больше, чем знали раньше, о возможностях TDD.

Вы можете найти решение. Вам не нужно знать это заранее.

Я написал эту серию, потому что Интернет утратил основы TDD. В Интернете полно статей о TDD; только эти статьи не объясняют Первые принципы.

Когда кто-то спрашивает меня, мне очень трудно предоставить хороший источник, объясняющий TDD для баребонов. Большая часть контента скрыта внутри книг, которые ничем не отличаются от веб-сайтов с платным доступом.

Интернет открыт и бесплатный, но он также забывает.

Надеюсь, вы не забудете этого.

Спасибо за прочтение. Если у вас есть отзывы, напишите мне в Twitter, Facebook или Github.

Благодарим Данила Сьюитса и Джейми Айзекса за их полезный вклад в этот пост.