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


Да, писал. К коду, который сам же и написал.

Суть юнит-тестов не в какой-то бюрократии или 100% покрытии, а в подготовке кода к рефакторингу. Юнит-тестирование позволяет уменьшить вероятность, что что-то сломается при рефакторинге, а также предполагает переработку архитектуры кода в плане тестируемости. Эта переработка архитектуры подготавливает код к дальнейшему изменению, т.е. при добавлении новой фичи меньше вероятность, что придётся всё раскурочивать.

Замечательно..
Ну а теперь посмотрите о чём велась речь выше:

Цитата(kolobok0): "в том виде котором юзают юнит тесты они проверяют только изменение кода со временем. И больше ничего."

Цитата(vanner): "первая задача модульного тестирования - это проверка корректности работы функции (модуля), т.е.
проверка условия что при указаных входных данных получается корректный результат и/или корректная обработка ошибки.
Проверка регрессий это уже побочный эффект по-сути, при наличии ранее работоспособных тестов легко определить какое
изменение сломало модуль. "
(извините за полное цитирование)

Так, что уважаемый andrewlekar - наши с вами восприятия нахрена это нужно - имеют один вектор.
А вот господин vanner ожидает(насколько я его смог понять) = "проверка корректности работы функции" .

Я заострил внимание именно на организационном моменте. Т.к. именно он определяет качество самих тестов в
плане "корректности работы функции".
Объясняю:
Лично мне слабо понимается сам процесс написания кода программистом, и написание тестов к нему этим-же программистом.
Тесты в этом случае могут НЕ ВЫЯВИТЬ "некорректности работы функции". Т.е. вряд ли правая рука сможе
написать такого, что упустит в реализации левая. А левая вряд ли будет тестировать то, что НЕ написала(либо не знала) правая
рука одного и того-же человека.

Надеюсь мысль передал.
Остаётся только всё то вспомогательное которое не имеет отношения к качеству и уменьшению затрат при производстве
(читай при запуске в производство) программного кода. Т.е. если Вы допустили ошибку, то она честно и провериться с ошибкой
и уйдёт с ошибкой дальше....

ЗЫ
Забегая вперёд, отвечу - я не против механики. Я считаю, что метода хромает. Метода, которая увы и ах применяется повсеместно (противного
не наблюдал). Т.е. написал человек код, написал к нему тест... А как деление на ноль было так и осталось. Вряд-ли человек напишет проверку
выше по уровню знаний чем его же написанный код, который он тестирует.

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

А пример реальной функции которую вы подвергали юнит-тестированию можете дать?

Я расшифровываю понятие юнит-тестирование как тестирование элементарных функций (unit - единица, элемент)
Зачем нужно тестировать элементраные функции охватываемы взглядом, вроде таких: с = a + b, если вы в своем уме и доверяете глазам ?

Причина такой паранойи, на мой взгляд, может скрываться в объектных языках и объектных моделях.
Это свойственно C++ с переопределением операций, шаблонами и прочими фичами, и больше актульно программистам на PC которые пишут код не комприлируемый напрямую в ассемблер или базирующийся на объектных библиотеках представляющих собой черный ящик.
У них действительно простое сложение может дать непредсказуемый результат только из-за того, что где-то далеко в хидерах изменилось какое-то объявление или сменилась версия библиотек.

На нормальном C-и, раз взглянув на элементарную функцию и мысленно помоделировав ее выполнение можно дальше ее не тестировать.
Если же мысленно не тестируется, как например файловая система, то юнит-тестирование здесь ну никак не поможет и не встроится, надо писать макротестирование, делать логи, профилировать, проходить по шагам и только на целевой платформе.

Юнит тестирование применяется в больших иерархических проектах.

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

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

Если они одинаковые, то и тестировать надо 1 кирпич (и не тот, который потом пойдет в фундамент дома). Так же надо тестировать и все остальное - не из одних же кирпичей дом строят

Ну тогда дом будет построен из обломков.

Угу. Видел я некоторые системы, так они были построены даже не из обломков, а скорее из щебенки
в принципе при наличии нормальной системы тестирования продукта в целом, unit тесты уже как бы и не обязательны - баги будут пойманы все равно, но если интересует не факт наличия багов, а работающая целая система, то unit тесты - как говорится must have (или отладка такой системы может превратится в кошмар)

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

Это один из моментов зачем нужен TDD. Тест может содержать ошибку. Для проверки что сам тест правильный, он выполняется два раза - до написания кода (тест должен вернуть ошибку), и после.

Ваш пример показывает, что тест охватывает сам интерфейс, а не реализацию.
пример:

берём класс строка, который может содержать в себе и ноль так-же (ну например: стандартный CString от MFC).
Не всякий программист, обрабатывая строки это может осязать. Как следствие - режутся данные до нулевого символа.

Это как один из множества, и... "лёгкий" пример.
Поверьте мне дураку - таких нюансов очень и очень много.

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


Не, ну как - на каждый нюанс поведения функции свой тест.

Это все похоже не про встраиваемые системы.

А вот сегодня пришло из рассылки barrgroup: http://www.edn.com/design/automotive/44234...ts-consequences
Очень поучительная история про ошибку в систему управления TOYOTA которая привела к фатальным последствиям.

Эксперты по программному обеспечению NASA оказались бессильны (видать юнит-тесты пытались применить)
А в реальности это наименее важный момент.
Самое опасное это Single points of failure (SPOF), обнаружить которые не поможет ни один юнит-тест. Еще очень опасен программно-аппаратный симбиоз багов.
Вторая показательная ошибка - тестирование в отрыве от платформы. Переполнение стека RTOS ну очень сложно заметить моделируя софт на PC (чем наверно и занималось NASA) .

Есть там и интересные рекомендации по организации тестирования.

Интересна отсылка к оценке параметра под названием Cyclomatic complexity, как предсказателю количества ошибок.
Странно но в популярных IDE такой фичи не встречал.

Первая книжка про TDD, которую я прочитал и начал применять - именно "Test Driven Development for Embedded C".
Тут больше желание/возможности работника и работодателя, чем область применения.


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