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

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

Кстати, давайте сойдемся в определениях , для меня:
модульное тестирование - это уровень тестирования,
а TDD - это одна из методологий разработки софта

Хороший набор. Только интересно к каждому пункту добавить средства, которыми он достигается - инструменты и методы (я вкратце упомяну свои).

Для ответа на вопрос "почему" часто использую первые документы шаблона ReadySet (http://readyset.tigris.org/). Там довольно толковая "рыба".

На вопрос "что" хорошо ответят спецификации требований к программе. Я намедни не поленился и перевел стандарт IEEE STD 830-1998 (http://club.shelek.ru/viewart.php?id=344), там есть что почерпнуть, даже если не заимствовать его целиком.

В оформлении порой помогает indent. Также полезна бывает встроенная документация Doxygen, хотя не всем нравится.

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

Тут, пожалуй, оптимальнее всего объектно-ориентированное проектирование.

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

Один из классиков (не помню, кто именно; кажется, Джон Роббинс) расказывал, что в особо затруднительных случаях подробно рассказывает неудачный алгоритм своему коту, который умеет слушать лучше всех. Высказанная вслух нелепость сразу становится очевидной.

Тема просто огромная. Я, как и обещал, взялся за небольшую статейку (которая, впрочем, по ходу начинает пухнуть, поскольку одно цепляется за другое, и вроде бы ничего нельзя выкинуть без ущерба для понимания). Как только будет результат, оповещу дополнительно, но пару недель, скорее всего, на это потребуется.

Верно. Зачастую к тестированию относятся с таким же предубеждением, как староверы - к мирским благам: не пробовали, но слышали, что греховно. Попробовав же, убеждаются, что все не так уж страшно.

Не вижу большой крамолы, только если это сопровождается реальными делами, а не пустословием. В самом по себе управлении нет ничего опасного. К тому же эта дисциплина является обязательной при изучени программной инженерии согласно SWEBOK.

Погодите совсем чуток

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

P.S. Пока в виде временной меры черкнул несколько слов в своей Wiki: http://wiki.shelek.ru/index.php/TDD

Аналогично.

Я с Вашего позволения свои упоминать не буду, т.к. относятся к размеру предприятия и врятли представляют интерес для широкой публики

Хотя могу порекомендовать Trac (http://trac.edgewall.org/) для небольших команд.который приятно взять в руки.[/quote]



Крамолы тут нет, но "приключений" себе нажить можно , если Ваше начальство вдруг начнет бегать по офису с этими словами... Я имею в виду формальную аттестацию этой системы.

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

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

Наоборот, было бы удивительно, если бы тест для кода, которого еще нет, прошел нормально. Ведь на самом деле там пока еще пустая заглушка, которая лишь не вызывает ошибку компиляции, но ничего не делает. Когда тест даст сбой, мы можем удостовериться, что он на самом деле выполнился (например, мы не забыли добавить его в рабочий набор, что вполне может быть по запарке).

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

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

Напоминает студенческую байку: якобы некто в середине своей дипломной работы написал: "Катоды будем стругать из дерева, потому что до этого места все равно никто не дочитывает", и якобы эту фразу не заметили ни руководитель, ни рецензент, которым и вправду лень было дочитывать. Но такие комментарии - особый случай.
Отсутствие избыточности всегда идет на благо - не нужно тратить усилий на согласование дублирующих друг друга частей, как в приведенном выше примере с лишними комментариями.
Совершенно верно. Но я в данном случае говорил не о программировании, а о проектировании. Наверное, следовало выделить в тексте поярче, чтобы лучше бросалось в глаза. Реализовать объектно-ориентированную программу на "C без плюсов" вполне реально, по этой теме даже есть кое-какая литература, хоть ее и не густо. Точно так же, как структурно спроектированную программу вполне можно реализовать на "неструктурных" Fortran-IV или ассемблере.
Да, согласен, бюрократией можно задушить любое дело. Ну тогда, скажем так, управлять качеством втихаря, без шумных лозунгов, касаясь только сути.

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

Вот вам еще один из аспектов качества: использование нами средства должны соответствовать поставленным задачам и поддерживать технологии которые мы хотим применять.

В принципе ничего, вполне терпимо. Несколько многословнее, конечно, более трудоемко и подчас требует большей аккуратности. Но с учетом бонусов, которые приобретаем взамен (а тут и улучшенная структура программы, и возможность использования многочисленных паттернов, и рефакторинг, и комфортное тестирование с использованием мок-объектов, и еще много всякой полезной всячины), овчинка выделки очень даже стоит. Тем более что (между нами) "старший брат" C++, который думает про себя, что он объектно-ориентированный, тоже далеко не подарок, и тем не менее масса народу пользуются и даже порвут в холиварах любого, кто осмелится озвучить подобную мысль.
Я бы скорее отнес это к области комфорта для разработчика, эффективности разработки, рентабельности и так далее. Вполне реально ведь и на ассемблере создать весьма качественный продукт, хотя это и потребует намного больше усилий и времени (плюс на данный момент мне не известно ни одного доступного средства для автоматизированного тестирования программ на ассемблере, хотя разработчики инструментальных средств уверяют, что работа в данном направлении ведется). Так что это соответствие - желательное, но не определяющее по части качества, разве что косвенно.

А теперь давайте посмотрим на процитированные слова несколько абстрактно, отвлекшись от идеи объектного программирования на С и вернувшись к теме качества. Вот они: "многословнее", "более трудоемко" и "требует большей аккуратности" - согласитесь все они могут повлиять на качество и увы не лучшим образом. А вот если "коротко", "легко" и "понятно", тогда почему бы хорошо не сделать

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

Два последних варианта я считаю совсем малоприемлемыми, остается первый.

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

Качество же как таковое должно соответсвовать ожиданиям пользователя, а если оно их немного превосходит, то он будет счастлив

Немного не понял сказанное, чем не устраивает обьектно-ориентированный язык C++ ? В чем этот язык не подарок?

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

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

Вот, например, Eclipse Helios содержит менюшку Refactor - вроде как оно самое... и че с ним делать? скрипты какие-то...

Давайте начнем с модульного тестирования. И тема довольно-таки простая (по крайней мере, мне она кажется на порядок попроще рефакторинга для начала), да и последовательность правильная: рефакторинг без модульного тестирования не делается (или делается разве что отчаянными парнями), а тестирование без рефакторинга вполне обойдется (хотя с ним все же гораздо лучше).

Итак, вооружаемся. Сразу же оговорюсь: все продукты бесплатны, никакого вареза нам не потребуется.

Прежде всего нам понадобится сам инструмент для модульного тестирования. Сразу же оговорюсь, что он не единственный, есть и другие. Чтобы продолжать дальше говорить на одном языке, давайте возьмем тот, на котором я сегодня остановил выбор: Unity. Берем его здесь: http://sourceforge.net/projects/unity/

Далее. Для облегчения некоторых рутинных действий авторы Unity (и сопутствующих ему продуктов) разработали несколько скриптов на языке Ruby. Поскольку Ruby - язык интерпретируемый, то для выполнения программ на этом языке нам, разумеется, потребуется интерпретатор. Берем здесь и устанавливаем: http://www.ruby-lang.org/en/downloads/ . Не волнуйтесь, знание самого языка нам совершенно не потребуется (хотя это знание в дальнейшей работе даст свои плоды, поскольку многое по части автоматизации сейчас делается на Ruby, например, инструмент для сборки проекта Rake, который имеет ряд преимуществ перед стареньким make).

Раз уж мы взялись за качество и красоту кода, не повредит обзавестись компактным и в то же время мощным средством для обработки ошибок времени исполнения в программе наподобие того, как это делается в более развитых языках, - CException: http://sourceforge.net/projects/cexception/ . К тому же я планирую использовать его в примерах к будущей статье.

Если есть желание немного забежать вперед паровоза, можно авансом скачать генератор мок-объектов CMock: http://sourceforge.net/projects/cmock/ . Сразу предупреждаю, что браться за него, не освоив как следует модульное тестирование, бесполезно. Но если кто-то хочет запастись впрок - почему бы и нет?

Ну и последнее. Нам понадобится среда для экспериментов над всем этим безобразием. Вообще говоря, все перечисленные инструменты прекрасно работают с ANSI C, а поскольку фактически все современные компиляторы достаточно хорошо с ним совместимы, серьезных проблем не должно возникнуть, что бы вы ни выбрали, будь то "родной" компилятор для IBM PC или кросс для AVR, PIC или другой платформы. Я получал одинаковые результаты и в среде MS Visual studio 2008 C++, и в GCC, и в WinAVR. Моя предпочтительная среда - Code::Block+Cygwin для PC/Windows и WinAVR либо AVR Studio 5 для AVR. (Да, я знаю, что есть компиляторы, выдающие более качественный объектный код, чем GCC; однако возможность выполнять один и тот же код как на PC, так и на AVR перевешивает для меня эти недостатки GCC. Кроме того, я не исключаю возможности перехода в ближайшем будущем на другие платформы, и рассчитываю на то, что всеядность GCC поможет мне в этом). Скачать связку Code::Block+Cygwin можно здесь: http://www.codeblocks.org/downloads/26

Ожидание выхода в свет обещанной статьи можно пока скрасить чтением прилагаемой к скачанным продуктам документации, а также моей совсем небольшой статьи по применению CException: http://club.shelek.ru/viewart.php?id=343

Отправил на рецензию первую часть статьи (ликбезную). Попросил опубликовать по возможности без задержек.

Отпишусь, как появится в общем доступе.

Update: первая часть опубликована, можно читать: http://club.shelek.ru/viewart.php?id=348

Всем привет!
A Goldsmith большое спасибо за интерсные ссылки и статью.

1) Как IDE я бы порекомендовал осваивать Eclipse со товарищи. Из преимуществ:
- поддержка практически всех "стоящих" языков программирования;
- интеграция с большинством систем контроля версий;
- поддержка рефакторинга и форматирования для большинства языков ;
- поддержка поиска и навигации по артефактам проекта (например, классам, функциям и т.п.);
- интеграция с билд системами и системами прогонки тестов;
- интеграция с системами управления дефектами;
- gcc + gdb незабыты конечно
и.т. и д.п.

3) Компилятор gcc - может он иногда не самый лучший, но разобравшись с ним можно легко "перетекать" с платформы на платформу, да и информации по нему в интернете море.

4) Система контроля версий наверное Mercurial, git не пробовал поэтому ничего сказать не могу.

5) Что касается CException то тут надо очень хорошо понимать, что она делает. Были такие ребята Symbian OS назывались, так вот они тоже примерно такое же в C++ затолкали, т.к. на 1997 год GCC exception для ARM толком не поддерживал да и типа ресурсов exception много потребляет. Так у них потом стоимость разработки была в разы выше чем на стандартном С++ Хотели в 2000-х нормальное приделать ан нет все longjump-ами "разносит".

! Да, кстати, они к именам функций "выбрасывающих" подобные exception добавляли спец. суффикс, что бы их не прозевать....!

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

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