Я с тобой категорически не соглашусь. Юнит-тестирование и дебаггинг - это 2 разные части процесса создания качественного софта. Но ни одно из них не является частью другого, хотя и взаимодействуют.
Дебаггинг, как даже из его названия видно, это устранение багов, т.е. ошибок. Для этой цели можно использовать юнит-тестирование, но вовсе не обязательно. Более того, даже при полном отсутствии юнит-тестирования можно (и приходится) заниматься дебаггингом
Точно также, запуск юнит-тестирования вовсе не означает "устранение ошибок". Это может быть просто проверка, что ошибок нет. А при отсутствии ошибок говорить о дебаггинге как-то странно, мягко говоря.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

Первое определение в google

debug
diːˈbʌɡ/
verb
gerund or present participle: debugging
1.identify and remove errors from (computer hardware or software).
"games are the worst to debug"
2.detect and remove concealed microphones from (an area)

Да но только на очень поверхностном уровне-слоя отдельных компонентов системы, одним словом это анализ "поломок".

Пришел в автосервис а тебе на компьютере показывают места которые не прошли unit tests.

Ошибка в двигателе, тест не пройден.Разбирайтесь сами. (Указание неисправности на конкретный компонент системы)

Как же разные? Разные, это когда независимые. Есть действительно разные части процесса создания.
1. Проектирование
2. Изготовление
3. Тестирование
4. Сдача/приемка

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

Чтобы небыло разнотолков, перевод слова "debugging" в гугле - отладка. Ты будешь смеяться, но и "отладка" гуглом переводится на английский, как debugging. Так что определение это давно вышло из "устранение жучков". Определение из википедии я уже приводил.

Так вот, юнит-тестирование, это часть дебаггинга. Пусть, как говорит Oyeme, на очень поверхностном уровне. Разницы нет на каком уровне. Вот из википедии про юнит-тесты:

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

Совсем не обязательно, чтобы баги присутствовали. Важно убедиться, что их нет. В любом случае процесс дебаггинга всегда начинается и заканчивается тестом, а не исправлением. На нем может и прекратиться. Так что не может быть дебаггинга без тестирования. А значит, это единый процесс.

UPD Один умный дядька мне как то сказал. Программа, заработавшая с первого запуска - повод для паники. По твоей логике её не нужно дебажить (отлаживать). Раз работает. Так вот нет - как раз если хочешь иметь качественный продукт - готовься к дебаггингу. И горе тебе, если не найдешь ни одной ошибки.



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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Так и не нашел откуда цитата и с чем она связана, поэтому лишь предположение.

Скрининговое обследование в больнице не является частью лечения. Есть например болезни, которые лечения и вовсе не требуют или не поддаются. Юнит-тестирование не часть дебагинга, просто автоматизация. Любое ПО требует тестирования, оно в любом случае будет осуществлено в каком-то виде: либо клиентом, либо отделом тестирования, либо программистом (что предпочтительно, но не всегда выполнимо в надлежащем объеме).

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

Оказывается когда случайно натыкаюсь взглядом на явный баг в коде, это я дебаггингом занимался? Или тестированием? Поэтому дебаггинг совершенно определенный процесс, связанный непосредственно с устранением выявленных ошибок.

Уточню только, что дебаггинг - это сначала поиск, потом устранение... А со всем остальным согласен полностью

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

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

Вот только какой смысл обследования, если потом не лечить найденые болезни? И кстати, нет таких болезней, которые не лечатся. Не излечиваются - да. Но даже рак, диабет и даже спид лечат, облегчая симптомы и продлевая жизнь. Но это лирика.

Соглашусь, тестирование может существовать без лечения. Можно провести те же юнит-тесты и отдать заказчику список багов. Да, тестированием может заниматься тестировщик, который понятия не имеет, как эти баги устранять. Но.

Не бывает устранения ошибок без тестирования. Еще раз - любой дебаггинг обязательно начинается с теста. И обязательно им заканчивается. Если тест не пройден, дебаггинг не завершен.

Так что как не крути, можно конечно медицину использовать на половину её возможностей. Пройти обследование, и ходить потом плакать - у меня в левой пятке артрит. Ничего при этом не делая. Но правильно ли это? И делается ли так в производстве ПО?

Поэтому юнит-тестирование глупо рассматривать, как отдельный, самостоятельный процесс. Это часть дебаггинга. Даже если багов не найдено.

По крайней мере, я не вижу другого предназначения юнит-тестов, как выявление возможных логических ошибок для их устранения. Что можно в конце итога сделать полезного с найдеными ошибками, кроме как это?

А значит логично предположить, что юнит-тест, это дебаггер и есть по своей сути.

Вернее его часть, интерфейс. Дебаггер, это PHPUnit в нашем случае. Что сути не меняет.

Кстати говоря, сам дебаггер ошибок никогда не исправляет. Только находит их (ну или не находит, выдавая вердикт - годно). Не смотря на название.

Это его дело. Как говорится - ноги, крылья. Я лучше один раз потрачу время на удобный мне дебаггер, а потом, с помощью него, сэкономлю кучу времени на разработке, чем буду тыкаться как слепой кутенок. Вот к примеру, как увидеть результирующий текст "подготовленного" SQL запроса в PDO, особенно если он собран динамически? Я один раз написал приблуду и доволен как слон.

Да и вообще, дядя Боб вовсе не такой дебаггинг имел ввиду, какой мне нравится. Как выясняется.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Пример про больницу не раскрыт до конца...
Из за чего пациент пошел на обследование? - из за того, что он провел юнит тестирование и понял, что - "где то поломка/не тот результат/перегрев и т.д.". После чего в больнице ему снова проведут "тестирование", но уже своими юнит тестами и найдя или не найдя "причину/поломку", начнут "дебажить" или не начнут соответственно.

Метафора №2.
Собирают автомобиль...
После сборки его можно Да можно конечно ожидать от клиента жалоб в виде - заработал автомобиль вообще или нет, но при проявлении проблемы, придется отзывать машину, и устранять проблему, потом снова отдавать клиенту и так по кругу, это не правильный путь.
Отдел тестирования - вот он и будет запускать все нужные тесты, что бы в случае чего - дебажить...
Программист - он занят по факту всегда , ему не до дебагинга и юнит тестов

Не знаю, как другие программисты, но у нас в команде все программисты занимаются дебаггингом своего кода в процессе разработки. Но никто из них не занимается юнит-тестированием.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

Если не анекдот, у меня сестра перинатолог, лечит новорожденных. Тоже издевается, зачем мне стетоскоп, если я всё спрашиваю.

_____________
Бесплатному сыру в дырки не заглядывают...

Например, когда лечение слишком долгое или тяжело переносится больным. Мало смысла лечить то, что не угрожает жизни и не приносит особого дискомфорта. На пенсии если сидишь и давишься бездельем, тогда да. Но действительно лирика, не будем уходить далеко в сторону.

Тестирование подразумевает явный процесс проверки. Что если я умозрительно нашел баг, исправил его, и умозрительно убедился что все работает как нужно. Это же не тестирование (разве что моего мозга ). Так что нет, тут я не согласен, что любой дебаггинг начинается и заканчивается тестированием. =)

Другой пример:

Написал юнит-тест под экзамен для студентов. Задача теста определить правильность выполнения задания перед тем как оценить эффективность алгоритма. Вот вам пожалуйста юнит-тестирование никак не связанное с дебагом. Я, как преподаватель, никакого отношения к дебагу не имею. Более того, мне вообще плевать, тест не пройден, ставлю неуд и всё. Смог воспользоваться юнитами, значит они не жестко связаны друг с другом и являются вполне себе самостоятельными.

Из-за того что скрининговые обследования положено делать раз в определенное время. На них благополучно забивают, у нас медицина добровольного характера, за некоторым редким исключением.

Как поступить потом: лечить, отложить, или сразу в морг - дело второе. Главное, что процесс отладки (дебаггинга) запущен с началом теста. Он может быть прерван, либо закончен без устранения багов (если их нет), но это всё равно процесс дебаггинга (отладки).

А это чистая теория. Никто в здравом уме так не делает. По крайней мере ни кому не придет в голову не убедиться в этих умозаключениях практически (протестировать как наличие бага, так и его отсутствие после исправления). Только ради спортивного интереса, как игра в шахматы вслепую. Если не он сам, значит тестить будет заказчик. Хуже всего, если вживую.

У меня жена работает поверителем. Проверяет корректность работы приборов. Она тестировщик. Проверяет допустим частотомер. Она никакого отношения не имеет ни к промышленному использованию, ни к ремонту частотомеров. Но контора у них называется РПП. Ремонтно-Поверочный Пункт. И она - часть системы. И эталонный частотомер - всё равно частотомер.

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

И если ты не имеешь прямого отношения к процессу исправления ошибок, и твой тест не предназначен для их исправления, он не перестает быть тестом. А значит дебаггером. Просто вы ищите баг не в самой программе, а в башке у студента, и пытаетесь исправить его, поствив "неуд" в зачетку.

UPD Процесс обучения, это не процесс производства ПО. Так что пример вообще некорректен.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.