Нужно ли юнит тестирование для прог написанных на низкоуровневых языках (c, аsm) или лучше с отладчиком работать если нужно, то как это можно организовать? интересует как можно подать данные на вход функции/модулю, что подавать, как проверять корректность, как все это реализовать и т.д.
Зависит от много. Один ты или много людей. Как тимлид решит в конце концов. Классика жанра gtest. Манов куча как и примеров. Работает это просто. Тест это отдельный блок который что-то проверяет. Потом в этом блоке в конце ассерт который проверяет результат. Например ты тестишь парсер пе файла. У тебя есть 5 файлов (жутко извратных). И ты делаешь 5 тестов, в каждом например ищешь какое-то поле и в конце теста говоришь - нашел или нет (в ассерте проверяешь). Как-то так.
для тупых кодеров ни в чем нет смысла... юнит тесты же эффективны в тдд и девопсах... когда есть некая тулза, которая автоматом гоняет юниттесты при каждом коммите например... либо как минимум если существует какой-то регламент у команды разработчиков, когда руками гонять юнит тесты, и все ему адекватно следуют... в противном случае это будет неэффективно и будет только отнимать время...
А что это, новый термин экзотический Я знаю как функу на стрес тесты прогнать, что бы например упало всё.. а что такое юнит-тесты" - хз. Наверно есчо немного автоматики, решили задачу по солверам, если нет, тогда это просто новый термин для пиара, описывающий мамонтов.
Скока букафф!) Тема тестирования холиварна изначально. Все зависит от подхода и кол-ва людей. И да - это дорого и дольше. Не все могут позволить себе платить кодеру, чтоб он сраные тесты писал.
Ну test-driven development КМК это для веб макак полезная тема. Я вот сейчас с проектом работаю, в нём овер 800 килострок. А все знают, что на каждую строку исходного кода нужно 3-5 строк unit-теста. Ну и где прикажете найти 5-7 лет человек-часов на это? Уже не говоря о том, что имею множество функций, результат которых известен только примерно (моделирование). И что в команде есть старый дебил который не понимает зачем нововведения, который пишет на всём чём может как на турбопаскале. Этого уже достаточно, для того чтобы забить ## на юнит-тесты во благо выката продукта.
Юнит-тестирование полезно. Сам заметил, что лучше на всякий случай написать тест для отдельных функций, нежели потом ловить баги. Особенно актуально, когда переписываешь нативный код в векторизованный SSE/AVX и т.д. Другое дело, что оно не всегда применимо, или сложно, ввиду чего приходится пилить свой фреймворк.
Юнит-тестирование полезно при разумном применении. Для тестирования отдельных функций, которые либо сложны, либо будут модифицироваться/переписываться/оптимизироваться.
