Поскольку я вдоволь наслушался аргументов типа «ну мы уже столько тут написали, что переделать это не реально», или «а зачем? оно же как то работает — будем поддерживать» что бы не упало, то позволю себе согласится с автором статьи.
Я стараюсь ставить вопрос иначе: Хотим мы внедрять, что либо новое, или нет? Нужен ли нам этот опыт?
И все сводится только к этому. Если в команде есть разработчики, которым уже надоело сидеть в тихом и спокойном болоте, то либо они получают интересную задачу и boost по скилам, либо мы их теряем.
Но бывает и так, что команда действительно не хочет ничего внедрять и занимается целый день всем, чем угодно, только не разработкой. И это считается нормальной работой, если конечно не случится какой нибудь пожар.
В общем, если желания нет, то никакие аргументы из серии «быстрее, выше, сильнее!» не будут восприняты.
Хороший материал. Спасибо.
Есть ряд вопросов.
1. Позволяет ли TS_EXPECT_CALL задать очередность вызовов одной и той же функции? Например, первый раз вернуть 10, а второй 20.
2. Как обстоят дела с указателями в параметрах? Например, если параметр есть указатель на структуру. Что в этом случае проверяется в реализации мока — указатель, поля структуры или просто область памяти по sizeof? (я пишу на С и не силен в C++, поэтому объектов не касаюсь)
3. Потокобезопастность (есть или нет)
Да… и за этот способ тоже благодарен.
Мне и в голову не приходило. Но возьму на заметку. Иногда коллеги-разработчики не хотят менять код ни на символ, а тестировать надо. Вот и пригодится :)
За способ спасибо. Не знал, что так можно.
Но с утверждением
Проще и чище, чем подгонять тестируемый код под тесты.
позволю себе не согласится. Это только кажется, что код «подгоняется» под тесты. А по-факту, получается очень качественный и легко поддерживаемый код (это я не про #ifdef UNIT_TEST конечно же).
Простите ради Бога.
Я не очень понял. В вопросе сесть сарказм? Или же Вы серьезно спрашиваете «Что мы делаем не так»?
Если сарказма нет, то мне не ясно, что Вас беспокоит? Почему Вы решили, что что-то делаете не так?
Какой-то сеанс психотерапии получается, к сожалению :(
Спасибо за версию на C++. Впечатляет.
К сожалению, есть проекты которые не приемлют C++. И это не хорошо и не плохо. Просто такие требования заказчика.
Это не так. И данная статья именно про это.
За «вакуум» прощу прощения. Думал, что пример связанного списка будет всем понятен как академический. Но выстрел оказался мимо. Теперь ясно о чем еще следует написать.
Я думаю, мы оба понимаем, что Вы хотите видеть полноценный проект. Разработку ПО от начала и до конца плюс тесты.
Это во-первых не реально уместить в одну статью, во-вторых, я пока не готов проделать такой объем работы ради плюсиков или минусиков в Карму :)
Но помочь обещаю. Постараюсь объединить пару периферийных модулей в некое рабочее приложение и оформить в виде статьи. С тестами разумеется.
А пока рекомендую установить ceedling. После установки Вы сможете подробно изучить пример, который идет в комплекте с этим инструментом (ceedling examples). Если не ошибаюсь, там какой-то измеритель температуры (прощу прощения за неточную информацию, давно туда не смотрел).
Я как бы и не говорю, что TDD — это наше все. Здесь мой выпад во вполне конкретную сторону.
Есть пред-история. Написание тестов, что называется «по-коду» не дает понимания преимуществ TDD. И если это не «переключить» в голове, то первая строчка теста написанного до написания кода будет
extern void * list_head;
Ну а дальше уже по известной схеме (сам так начинал). И тут уже не важно, тестами вперед или, в…
Ну это нормально. Бизнес, и все такое. Клиенту ведь не тесты нужны, а продукт. Если у Вас получается делать его хорошо без тестов, то проблемы то и нет.
Я — не очень внимательный человек, по своей природе. И тесты часто меня страхуют от ошибок. Я без них уже не могу работать. К хорошему быстро привыкаешь :)
Согласен, но мне показалось, что делать пост еще длиннее уже не прилично.
почему программисты не любят юнит-тесты
потому, что далеко не всегда умеют их писать, и как следствие — не видят в них смысла (просто из личного опыта, никого не хочу обидеть)
и что с этим делать
Учиться, учиться, еще раз учиться.
Писать тесты на основе поведения и открытого апи? И все?
Поверьте, это не мало.
«Проваленные» тесты совсем не означают, что какая-то функциональность не работает
Это вот о чем. Если тесты основаны на подробном знании внутренностей модуля, то банальное переименование list_head в listHead «провалит» нам все тесты. Но модуль как был работоспособным, так и остался.
Поймите меня правильно. Я не стремлюсь кого-то убедить или же доказать истинность того, что я написал. Это просто моя точка зрения. И выводы сделаны из личного опыта.
По порядку:
1. Не верю, что TDD приводит к качественному коду. Ну написал я тесты, потом написал код, чтобы они проходили и чего?
Это действительно так (в смысле действительно приводит), если изменить свое отношение к тестам и понимание их смысла. Простите за отсутствие конкретики. Для полноценного объяснения потребуется написать статью (я постараюсь это сделать в ближайшее время).
Может быть вы еще считаете, что тестирование (любого вида) способно выявить насколько код легко масштабируем, читаем и легок для изменений в будущем?
Нет, это не так. Масштабиреум — неверное да. Читаем — совсем не обязательно. Легок для изменений в будущем — да, потому что есть тесты в качестве regression.
Вы имеете ввиду, что ручным тестированием нельзя проверить работоспособность всего кода?
Нет, я не об этом. Просто определенные вещи нельзя покрыть юнит-тестами, если не думать об этом заранее. Думаю всем поклонникам TDD известно, что паттерн Singleton не есть хорошо. Его поведение только мешает тестированию.
elkews, Вы не будете возражать, если я положу нашу с Вами дискуссию в основу статьи на Хабре?
Позволю себе уточнить пару моментов:
1. TDD, BDD и прочее неизбежно приводят Вас к качественному коду, если, конечно, овладеть умением писать хорошие тесты;
2. При всем стремлении к качеству кода, я почти на 100% уверен, что некоторые его места практически невозможно протестировать в виду тех или иных технических решений, принятых без учета тестирования;
Тестируемость кода, есть один из критериев его качества, на мой взгляд.
А по времени — разработчик, хорошо владеющий TDD (BDD) выдает «на-гора» протестированный платформо-браузеро-БД-независимый код за тоже время, что тратит «write-build-press-print-debug» разработчик на создание такого же функционала, но без всего этого сахара. Не хочу никого обидеть, просто мне не доводилось работать с людьми, которые пишут код круто и с первого раза. Про таких ходят легенды…
Дизайнеру респект.
Смотрятся привлекательно, как по мне. Хотя и крупноваты, особенно мужские. Мне кажется на мужской руке любые «куранты» на тоненьком ремешке не есть хорошо, но это, опять же, на мой вкус. Должна быть пропорция между шириной ремешка и шириной самих часов.
Да, еще, если эти «часы» не будут показывать время, а для его отображения, судя по всему, просто нет места, то далеко не каждый захочет носить такой гаджет на руке. Просто смысла нет. Помимо «бесспорно интересных» функций должны быть и «просто полезные» (часы, дата, будильник ...)
Желаю удачи в осуществлении Вашего проекта.
Я стараюсь ставить вопрос иначе: Хотим мы внедрять, что либо новое, или нет? Нужен ли нам этот опыт?
И все сводится только к этому. Если в команде есть разработчики, которым уже надоело сидеть в тихом и спокойном болоте, то либо они получают интересную задачу и boost по скилам, либо мы их теряем.
Но бывает и так, что команда действительно не хочет ничего внедрять и занимается целый день всем, чем угодно, только не разработкой. И это считается нормальной работой, если конечно не случится какой нибудь пожар.
В общем, если желания нет, то никакие аргументы из серии «быстрее, выше, сильнее!» не будут восприняты.
Есть ряд вопросов.
1. Позволяет ли TS_EXPECT_CALL задать очередность вызовов одной и той же функции? Например, первый раз вернуть 10, а второй 20.
2. Как обстоят дела с указателями в параметрах? Например, если параметр есть указатель на структуру. Что в этом случае проверяется в реализации мока — указатель, поля структуры или просто область памяти по sizeof? (я пишу на С и не силен в C++, поэтому объектов не касаюсь)
3. Потокобезопастность (есть или нет)
Я бы назвал это авантюризмом. Ведь попытки делаются не ради боли :)
Мне и в голову не приходило. Но возьму на заметку. Иногда коллеги-разработчики не хотят менять код ни на символ, а тестировать надо. Вот и пригодится :)
Но с утверждением позволю себе не согласится. Это только кажется, что код «подгоняется» под тесты. А по-факту, получается очень качественный и легко поддерживаемый код (это я не про #ifdef UNIT_TEST конечно же).
Я не очень понял. В вопросе сесть сарказм? Или же Вы серьезно спрашиваете «Что мы делаем не так»?
Если сарказма нет, то мне не ясно, что Вас беспокоит? Почему Вы решили, что что-то делаете не так?
Какой-то сеанс психотерапии получается, к сожалению :(
Просто ceedling гарантирует порядок выполнения тестов. Вот я позволил себе слабость :)
К сожалению, есть проекты которые не приемлют C++. И это не хорошо и не плохо. Просто такие требования заказчика.
В этой фразе нет ни одного лишнего слова.
За «вакуум» прощу прощения. Думал, что пример связанного списка будет всем понятен как академический. Но выстрел оказался мимо. Теперь ясно о чем еще следует написать.
Это во-первых не реально уместить в одну статью, во-вторых, я пока не готов проделать такой объем работы ради плюсиков или минусиков в Карму :)
Но помочь обещаю. Постараюсь объединить пару периферийных модулей в некое рабочее приложение и оформить в виде статьи. С тестами разумеется.
А пока рекомендую установить ceedling. После установки Вы сможете подробно изучить пример, который идет в комплекте с этим инструментом (ceedling examples). Если не ошибаюсь, там какой-то измеритель температуры (прощу прощения за неточную информацию, давно туда не смотрел).
Есть пред-история. Написание тестов, что называется «по-коду» не дает понимания преимуществ TDD. И если это не «переключить» в голове, то первая строчка теста написанного до написания кода будет
Ну а дальше уже по известной схеме (сам так начинал). И тут уже не важно, тестами вперед или, в…
Разработку какой системы на микроконтроллере Вы хотели бы видеть с тестами в рамках одной статьи?
Я — не очень внимательный человек, по своей природе. И тесты часто меня страхуют от ошибок. Я без них уже не могу работать. К хорошему быстро привыкаешь :)
потому, что далеко не всегда умеют их писать, и как следствие — не видят в них смысла (просто из личного опыта, никого не хочу обидеть)
Учиться, учиться, еще раз учиться.
Поверьте, это не мало.
Это вот о чем. Если тесты основаны на подробном знании внутренностей модуля, то банальное переименование list_head в listHead «провалит» нам все тесты. Но модуль как был работоспособным, так и остался.
По порядку:
Это действительно так (в смысле действительно приводит), если изменить свое отношение к тестам и понимание их смысла. Простите за отсутствие конкретики. Для полноценного объяснения потребуется написать статью (я постараюсь это сделать в ближайшее время).
Нет, это не так. Масштабиреум — неверное да. Читаем — совсем не обязательно. Легок для изменений в будущем — да, потому что есть тесты в качестве regression.
Нет, я не об этом. Просто определенные вещи нельзя покрыть юнит-тестами, если не думать об этом заранее. Думаю всем поклонникам TDD известно, что паттерн Singleton не есть хорошо. Его поведение только мешает тестированию.
elkews, Вы не будете возражать, если я положу нашу с Вами дискуссию в основу статьи на Хабре?
1. TDD, BDD и прочее неизбежно приводят Вас к качественному коду, если, конечно, овладеть умением писать хорошие тесты;
2. При всем стремлении к качеству кода, я почти на 100% уверен, что некоторые его места практически невозможно протестировать в виду тех или иных технических решений, принятых без учета тестирования;
Тестируемость кода, есть один из критериев его качества, на мой взгляд.
А по времени — разработчик, хорошо владеющий TDD (BDD) выдает «на-гора» протестированный платформо-браузеро-БД-независимый код за тоже время, что тратит «write-build-press-print-debug» разработчик на создание такого же функционала, но без всего этого сахара. Не хочу никого обидеть, просто мне не доводилось работать с людьми, которые пишут код круто и с первого раза. Про таких ходят легенды…
P.S.: я просто очень люблю юнит-тесты :)
Смотрятся привлекательно, как по мне. Хотя и крупноваты, особенно мужские. Мне кажется на мужской руке любые «куранты» на тоненьком ремешке не есть хорошо, но это, опять же, на мой вкус. Должна быть пропорция между шириной ремешка и шириной самих часов.
Да, еще, если эти «часы» не будут показывать время, а для его отображения, судя по всему, просто нет места, то далеко не каждый захочет носить такой гаджет на руке. Просто смысла нет. Помимо «бесспорно интересных» функций должны быть и «просто полезные» (часы, дата, будильник ...)
Желаю удачи в осуществлении Вашего проекта.
попробуйте IAR. Вам тогда Eclipse манной небесной покажется.
Хотя у каждой IDE есть свои плюсы.