Нам не нужны вонючие тесты
Я практикую и преподаю разработку программного обеспечения уже почти 20 лет. Имея удовольствие и привилегию работать со студентами бакалавриата и постуниверситета, а также с профессиональной аудиторией, мне все еще повезло практиковать то, что я проповедую в отрасли и в своих компаниях.
Я очень многому научился из вопросов, которые мне задавали, и ответов, которые мы искали. От простого наблюдения за студентами и написанным ими кодом до размышлений о том, почему они делают то, что делают. Чем больше я делал, тем более философски относился ко всему процессу. «Счетчик», просто для примера, — плохое имя для переменной. Мы все это знаем. Это учение много лет назад научило меня тому, почему. Переменные похожи на коробки. Вы маркируете их по тому, что находится внутри (например, numberOfLinesPrinted), а не по тому, что вы собираетесь делать с их содержимым (например, lineCounter).
Наша задача, как разработчика программного обеспечения, состоит в том, чтобы вести бесконечную битву с дублированием и зависимостями, получая массу удовольствия от решения головоломок в течение всего дня. В настоящее время мы можем проводить тесты, чтобы дать нам утешение, уверенность и уверенность в этом. Чтобы использовать возможности рефакторинга, практикуя коллективное владение кодом. Возможность анализировать то, что у нас есть, и то, что мы хотим.
За последние несколько недель я услышал, как мой коллега несколько раз говорил студентам, что писать тесты — хорошая идея, потому что они подтверждают правильность нашего кода. Я абсолютно согласен. За исключением того факта, что для меня реальная сила тестов заключается в их эффекте регрессии, а не столько в том, что они доказывают некоторую корректность (конечно, они подтверждают, поэтому мы их пишем). Один тест многого не стоит. На самом деле, он имеет довольно низкую отдачу от инвестиций. Настоящая сила теста заключается в том, что у него есть множество друзей, каждый из которых маленький и недорогой, и все вместе кусают нас, когда мы выходим за рамки. Если мы хотим создавать хорошее и удобное в сопровождении программное обеспечение, нам нужно развивать хорошие тесты вместе с ним!
Мы все знаем, что у нас проблемы, если мы видим 60-строчный метод (и я даже не преувеличиваю здесь), если нам нужен сервлет в конструкторе простого класса-контейнера или если нам нужно начать использовать горизонтальная полоса прокрутки в нашем редакторе. Со временем усложнение приводит любой программный проект без тестов к монолитному блобу, который начинает разрушаться при простейших изменениях при попытке провести хотя бы первый тест вокруг него. В какой-то момент код выйдет из-под контроля его создателей.
Код, который растет без тестов, трудно тестировать. Код, который трудно тестировать, трудно понять, не говоря уже о его изменении. Если мы хотим взломать код, нам нужно вырастить его внутри тестов. Если вы вырастите его внутри процветающего набора тестов, метод из 60 строк кода станет невозможным.
Снова и снова, когда я вижу связанный, слабо связанный код, я не удивляюсь, увидев рядом с ним тесты. Видел ли я чистый код без тестов. Конечно. Но задним числом это, вероятно, были ложные срабатывания.
Cherry выбирает то, что работает для вас, и будьте прагматичны в отношении того, что вы видите и копируете. Стремление к 100% тестовому покрытию — это когда люди (авторы?) перебарщивают и просто сосредотачиваются на «заявлении о правильности» тестов. Одно хорошее место для начала, когда у вас есть ошибка. Не вытаскивай пока. Сначала напишите тест, доказывающий его существование, а затем выпустите его. В итоге вы получаете тест бесплатно. Неплохой компромисс, если вы знаете, что ошибки имеют тенденцию накапливаться в устаревшем коде (то есть в коде без тестов).
Позвольте мне завершить это игрой, которую я представил студентам и профессионалам на протяжении многих лет. Я называю это тестер/кодер. Вы берете один ноутбук и перестаете говорить. На самом деле любое другое общение, кроме как через выбранный вами язык программирования, строго запрещено (и не пишите комментарии!). Тестер просто думает о простом предмете. Желательно небольшую игру или что-то в этом роде (ведь игры веселее). Тестер начинает писать неудачный тест, а затем передает ноутбук программисту, который должен попытаться запустить тест. Оба игрока могут читать код друг друга. Но изменить его не имеют права. Оба могут стать неприятными (поэтому допускается возврат 3; просто для запуска теста). Цель состоит в том, чтобы выяснить, насколько сложно быть выразительным в коде, имея проклятие знаний. Если вы хотите сделать ставку, просто достаньте шахматные часы и постарайтесь обыграть друг друга, используя как можно меньше времени. Отказ от ответственности: я видел, как люди увлекались этой игрой.
Всем менеджерам… пожалуйста, позвольте разработчикам программного обеспечения играть в игру и писать тесты. Вы будете удивлены долгосрочным эффектом производительности. Написание тестов (или предоставление людям возможности это делать) — не что иное, как ваше очередное удачное инвестиционное решение.
Моим ученикам… всегда весело!
P.S. Я не носитель английского языка. Так что, если это как-то помешало, мои извинения. Пожалуйста, не стесняйтесь связаться со мной и / или поделиться своими мыслями ниже.
