Говоря в повседневных, практических терминах, я думаю, что это полностью зависит от контекста .
В большой команде, работающей по высоким / очень высоким стандартам (например, банковские, военные, крупномасштабные, высокобюджетные или критически важные для бизнеса системы), я считаю, что «отладка» должна быть «результатом тестирования» , и они явно очень разные вещи . В идеале тестирование приводит к отладке (в промежуточной среде), а в производстве нам нужно близкое к нулю либо одно, либо другое.
Тестирование является широким по объему, регулярным и очень формализованным, в то время как отладка - это особый процесс, который иногда происходит, когда необходимо устранить конкретную ошибку, - который неочевиден и требует более глубокого изучения функционирования системы и получаемых результатов.
Здесь, на мой взгляд, тестирование является чем-то важным, в то время как отладка - это особый инструмент, необходимый только в случае непрозрачности разрешения ошибки.
Я полностью понимаю очевидную полезность TDD для больших команд и / или систем, которая просто не может позволить себе «глючить». Это также имеет большой смысл для сложных (часто «серверных») систем или если в коде есть высокая доля сложности по сравнению с выводом. Тогда у «тестирования» есть реальная возможность сообщить, когда и почему происходят сбои. Системы, которые выполняют большую сложную работу и / или дают отчетливо измеримые результаты, обычно легко тестируются, поэтому тестирование отличается от отладки. В этих случаях тестирование настоятельно предполагает формализованный метод подтверждения или отклонения соответствия ожиданий и фактического результата. Тестирование происходит постоянно и иногда сообщает нам о необходимости отладки.
Было бы прекрасно, если бы это была вездесущая правда, я бы хотел, чтобы мои циклы разработки были ограничены четко определенным двоичным выходом (красный, зеленый), но ...
В моем случае (что по общему признанию - работа на 98% соло на небольших и средних, недостаточно финансируемых веб-системах, ориентированных на данные корпоративных системах администрирования) я просто не могу понять, как TDD может мне помочь. Вернее, «отладка» и «тестирование» практически одинаковы.
Главным образом, хотя использование термина «тестирование» подразумевает / тесно связано с методологией TDD.
Я знаю, что это совершенно, совершенно не Zeitgeist "избегать неверующего, избегать, избегать", подлая и нехорошая вещь. Но, думая о моем контексте, с практической шляпой, я просто не смутно представляю себе, в моем самом смелом воображении вижу, как TDD может помочь мне повысить ценность денег для моих клиентов.
Вернее, я категорически не согласен с распространенным предположением, что «тестирование» - это процесс, основанный на формальном коде.
Мое основное возражение (применимо в моем конкретном * контексте *) заключается в том, что ...
Если я не могу написать код, который работает надежно - тогда, черт возьми, я должен писать код, который работает надежно, чтобы проверить, предположительно, нестандартный код.
Для меня я никогда не видел ни примеров, ни аргументов, которые (в моем конкретном контексте) приводили меня в восторг настолько, чтобы даже думать о написании одного теста , я мог бы написать какой-то смехотворно несущественный тестовый код прямо сейчас, может быть, «мой репозиторий возвращает пользователя сущность с Именем == X, когда я спрашиваю это точно - и только - что? ", но, возможно, во мне пишется эта потоковая передача, может быть," интернет-действительно-это-просто-просто-глупо-носик " Самоудовлетворительно-дико-под-информированным-кровью-кипящим-игнорирующим-расточительно-глупым мусором, но я просто чувствую необходимость сыграть здесь адвоката дьявола. (Надеюсь, кто-то покажет мне свет и превратит меня, может, в конечном итоге это даст моим клиентам лучшее соотношение цены и качества?).
Возможно, «отладка» иногда совпадает с «тестированием». Под этим я действительно подразумеваю, что в своей повседневной работе я трачу не менее трети своего времени, играя с локальной версией моей системы в разных браузерах, отчаянно пробуя разные дурацкие вещи, пытаясь сломать мою работу, а затем исследуя причины, по которым это не удалось и их исправление.
Я на 100% согласен с очевидной полезностью в мантре TDD «красный / зеленый / рефактор», но для меня (работа с низким бюджетом, земля соло-разработки RIA) я действительно очень хотел бы, чтобы кто-то показал мне, как я могу возможно , логически и жизненно реально получить какую-либо дополнительную ценность от написания большего ( как и потенциально некорректного тестового кода), чем от реального взаимодействия с полным (и по существу, только) результатом моих усилий, которые по сути связаны с реальным человеческим взаимодействием.
Для меня, когда разработчики говорят о «тестировании», это обычно подразумевает TDD.
Я пытаюсь кодировать, как если бы были тесты, я думаю, что все шаблоны / практики и тенденции, которые поощряла вся эта сфокусированная разработка, фантастические и красивые, но для меня в моем маленьком мире «тестирование» - это не написание большего количества кода, это фактически тестирование в реальном мире выводит его в реалистичной манере, и это практически то же самое, что отладка, или, скорее, активное изменение здесь - это «отладка», которая является прямым результатом неавтоматического «тестирования», ориентированного на человека. Это противоречит общепринятому представлению о «тестировании» как о чем-то автоматизированном и формальном, и о «отладке» как о чем-то человеческом, так и специальном или неструктурированном.
Если цель действительно стоит денег / усилий, и вы создаете интерактивные веб-приложения, то результатом усилий являются веб-страницы и очень существенно то, как они реагируют на человеческий вклад - так что «тестирование» лучше всего достигается тестированием эти веб-страницы, через реальное человеческое взаимодействие. Когда это взаимодействие приводит к неожиданным или нежелательным результатам, происходит «отладка». Отладка также тесно связана с идеей проверки состояния программы в реальном времени. Тестирование обычно связано с автоматизацией, которая, как мне кажется, часто является неудачной ассоциацией.
Если цель действительно стоит усилий, а автоматизированное тестирование является эффективным и очень выгодным, а отладка является либо просто результатом этого тестирования, либо плохой заменой автоматического тестирования, то почему второй веб-сайт по посещаемости в мире (Facebook ) так часто пронизаны ослепительно очевидными (для пользователей, но явно не для команды тестирования и кода тестирования) ошибками?
Может быть, потому, что они концентрируются на обнадеживающих зеленых огнях и забывают использовать результаты своей работы?
Не слишком ли много разработчиков считают, что тестирование - это то, что вы делаете с кодом, а отладка - это то, что вы время от времени делаете в IDE, потому что значок становится красным, и вы не можете понять, почему? Я думаю, что с этими словами связаны неудачные оценочные суждения, которые в целом затеняют практическую реальность того, на чем мы должны сосредоточиться, чтобы сократить разрыв между ожиданиями и результатами.