Мне кажется вы уже сами ответили на свой вопрос: CMake + CTest.

А есть ли в Cmake и Ctest возможность оценки покрытия кода тестами?

Честно говоря, без понятия даже как это (-: Почитайте и расскажите нам: http://www.cmake.org/Wiki/CMake_Testing_With_CTest

ctest может сливать информацию о покрытии в cdash, откуда он её берет фиг знает, никогда этой возможностью не пользовался

вот пример http://www.cdash.org/CDash/index.php?project=CMake

Посоветуйте, пожалуйста, систему автоматической сборки приложений(типа Ant) на С++

Вам именно НА С++, или то ДЛЯ С++? мы использовали Hudson, он на жабке, если что ;)

фреймворк для модульного тестирования

самый вменяемый из тех что видел - google test + до кучи есть google mock, но можно также использовать QTest хотя он и немножко наркоманский :) (зато не надо будет лишние либы тянуть/собирать)

Возможность определить покрытие кода тестами.

это для чего Вам, для формальной оценки качества работы программистов? какая методология разработки применительно у модульному тестированию у Вас используется? (если не секрет конечно)

>А есть ли в Cmake и Ctest возможность оценки покрытия кода тестами?

такая　возможность　есть　gcov+gcc а　cmake　и　компания　умеют　ей　пользоваться. так　что　для　начала　man gcov

>самый вменяемый из тех что видел - google test + до кучи есть google mock, но можно также использовать QTest хотя он и немножко наркоманский :) (зато не надо будет лишние либы тянуть/собирать)

Boost.Test тоже ничего - юзаю, доволен.

А вообще по unit тестам вот: http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle

Atlassian Bamboo

Ctest? Должен уметь.

>самый вменяемый из тех что видел - google test + до кучи есть google mock, но можно также использовать QTest хотя он и немножко наркоманский :) (зато не надо будет лишние либы тянуть/собирать)

Boost.Test тоже ничего - юзаю, доволен.

есть такое дело, но google test таки, у меня такое ощущение складывается, что более мощный и гибкий, рекомендую попробовать ;)

Atlassian Bamboo

хорош, но не бесплатен :)

и да, если уже его брать, то в комплекте с jira :)

Нет, к самой системе ограничений нет. Имеется в виду система сборки, поддерживающая программы, написанные на C/C++.

>>Возможность определить покрытие кода тестами.

это для чего Вам, для формальной оценки качества работы программистов?

ты не поверишь...

Нет, к самой системе ограничений нет. Имеется в виду система сборки, поддерживающая программы, написанные на C/C++.

ну тогда hudson - это наиболее распрстранённое и вменяемое из всего что я видел, к куче программных продуктов есть плагины, много где используется и всякое такое

>>Возможность определить покрытие кода тестами.

это для чего Вам, для формальной оценки качества работы программистов?

ты не поверишь...

спасибо, Капитан :)

но степень покрытия - это несколько формальный показатель, знаете ли, и совсем не гарантия что всё будет работать как надо

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

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

уф! успел ;)

отдел тестирования - это вторая линия обороны, первая - программисты и TDD

>отдел тестирования - это вторая линия обороны, первая - программисты и TDD

а может бизнес-аналитики и BDD?

и да, теперь ты объясни, каким боком покрытие кода должно было показывать что-то кроме покрытия кода? и как оно вообще связано с оценкой качества работы программистов.

>отдел тестирования - это вторая линия обороны, первая - программисты и TDD

а может бизнес-аналитики и BDD?

Вы у себя применяете BDD? лично для меня BDD видится несколько странной концепцией, больше похожей на test-first

теперь ты объясни, каким боком покрытие кода должно было показывать что-то кроме покрытия кода?

вещь в себе? ну-ну

и как оно вообще связано с оценкой качества работы программистов.

...и тестеров

уверены что надо отвечать на этот вопрос?

>лично для меня BDD видится несколько странной концепцией, больше похожей на test-first

ключевое слово: лично для тебя.

теперь ты объясни, каким боком покрытие кода должно было показывать что-то кроме покрытия кода?

вещь в себе? ну-ну

а багтрекер со списком открытых/закрытых тасков тоже вещь в себе? или все-таки показатель количества выполненной работы?

и как оно вообще связано с оценкой качества работы программистов.

...и тестеров

еще и тестеров. конечно надо: сначала - причем тут тестеры, потом - причем тут качество работы.

>лично для меня BDD видится несколько странной концепцией, больше похожей на test-first

ключевое слово: лично для тебя.

несогласны? обоснуйте

багтрекер со списком открытых/закрытых тасков тоже вещь в себе? или все-таки показатель количества выполненной работы?

ни то ни другое, странный Вы :)

конечно надо: сначала - причем тут тестеры,

отдел тестирования, помимо прочего, занимается написанием тестов (не во всех концепциях, но всё же)

про программистов - то же самое (тут уже чисто про TDD)

потом - причем тут качество работы.

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

в зале громкий смех изредка прерываемый всхлипами

>несогласны? обоснуйте

обосновать что? несогласие с твоим извращенным пониманием всего подряд? «BDD странная концепция, похожая на test-first». А test-first тоже странная? а выросший из test-first TDD? а упрощенный до возможности использования заказчиками и бизнес-аналитиками TDD, он же BDD?

ни то ни другое, странный Вы :)

ну так расскажи что же это такое и зачем это нужно. только желательно не в терминах «шайтан-машина которая пишет цифры, за которые хозяин приносит еду»

отдел тестирования, помимо прочего, занимается написанием тестов (не во всех концепциях, но всё же)

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

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

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

в зале громкий смех изредка прерываемый всхлипами

смех без причины - признак SIG_SEGV где-то в /dev/brain/modules

>несогласны? обоснуйте

обосновать что?

свою позицию, странно что это приходиться Вам объяснять :)

>отдел тестирования, помимо прочего, занимается написанием тестов (не во всех концепциях, но всё же)

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

а, так Вы ничего кроме unit-тестирования не знаете, тогда понятно :)

я тебе умный вещь скажу:

я уже сомневаюсь в истинности этого заявления

чем больше кода покрыто тестами - тем меньше осталось покрыть. не больше и не меньше.

хехе :) не зря сомневался, а сколько пафоса было

есть вменяемое объяснение для чего используется показатель покрытия кода тестами или продолжим «всхлипывать и смеяться»? ;)

>свою позицию, странно что это приходиться Вам объяснять :)

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

а, так Вы ничего кроме unit-тестирования не знаете, тогда понятно :)

про unit-тестирование начинался этот тред. JFYI

есть вменяемое объяснение для чего используется показатель покрытия кода тестами или продолжим «всхлипывать и смеяться»? ;)

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

«BDD странная концепция, похожая на test-first». А test-first тоже странная? а выросший из test-first TDD? а упрощенный до возможности использования заказчиками и бизнес-аналитиками TDD, он же BDD?

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

>свою позицию, странно что это приходиться Вам объяснять :)

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

жырненько сливаем

>а, так Вы ничего кроме unit-тестирования не знаете, тогда понятно :)

про unit-тестирование начинался этот тред.

не, тред начинался - да, и это прекрасно, но простите, контекст имеет свойство меняться, и Вы спросили:

и да, теперь ты объясни, каким боком покрытие кода должно было показывать что-то кроме покрытия кода? и как оно вообще связано с оценкой качества работы программистов.

я Вам ответил, Вы теперь ужом вертитесь отмазываясь и лепя горбатого

так держать!

>есть вменяемое объяснение для чего используется показатель покрытия кода тестами или продолжим «всхлипывать и смеяться»? ;)

для определения того, какой функционал покрыт тестами, а какой еще в них нуждается.

что Вы подразумеваете говоря «функционал»?

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

обождите, дойдём и до этого

так тебе померяться кто на стенку выше писает? ну давай перемещаться в другой тред и не оффтопить тут. кратко тезисы: «нет ты», «гвозди, микроскоп», «RTFM»

что Вы подразумеваете говоря «функционал»?

а есть варианты?

давай перемещаться в другой тред и не оффтопить тут

всё для Вас