Здравствуйте, Аноним, Вы писали:
А>Пишу на MS VS 2010, решил добавить тесты, добавил тестовый проект, добавил тест, смотрю — там .net, а как сделать чистый с++ тест?
В 2012 студии добавили нативный тест фреймворк. А пока самым лучшим вариантом будет скачать google test/boost test/cppunit.
Использовать managed test framework для тестирования нативного кода — очень, очень плохая идея.
Здравствуйте, landerhigh, Вы писали:
А>>Пишу на MS VS 2010, решил добавить тесты, добавил тестовый проект, добавил тест, смотрю — там .net, а как сделать чистый с++ тест?
L>В 2012 студии добавили нативный тест фреймворк. А пока самым лучшим вариантом будет скачать google test/boost test/cppunit.
Ну у меня пока только 2010
А интегрировать кого-то или всех из google test/boost test/cppunit в VS2010 можно как-то? Или просто добавить проект в проект и связать.
L>Использовать managed test framework для тестирования нативного кода — очень, очень плохая идея.
Здравствуйте, CEMb, Вы писали:
L>>В 2012 студии добавили нативный тест фреймворк. А пока самым лучшим вариантом будет скачать google test/boost test/cppunit.
CEM>Ну у меня пока только 2010
Кучеряво живете! Некоторые, вон, еще на 2005 пишут
CEM>А интегрировать кого-то или всех из google test/boost test/cppunit в VS2010 можно как-то?
Периодически появляются плагины то для одного, то для другого. Я их ставил, пробовал и сносил нафиг, потому что (см. ниже)
CEM>Или просто добавить проект в проект и связать.
Единственная интеграция, которая мне лично нужна, состоит в добавлении автозапуска тестового экзешника в Post-build step.
Да, нет легкой возможности выборочного запуска тест кейсов, но это не более чем небольшое неудобство.
L>>Использовать managed test framework для тестирования нативного кода — очень, очень плохая идея.
CEM>Это да
Здравствуйте, landerhigh, Вы писали:
L>Использовать managed test framework для тестирования нативного кода — очень, очень плохая идея.
чем плохая?
тем что тебе .NET не нравится чтоли?
я долго использовал MS Test для нативного С++ и никаких проблем не заметил.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, landerhigh, Вы писали:
L>>Использовать managed test framework для тестирования нативного кода — очень, очень плохая идея. A>чем плохая?
Проблемами. Которые вылезут не сразу, а когда одумываться будет уже поздно и будут сильно портить жизнь. Смотри ниже.
A>тем что тебе .NET не нравится чтоли?
Причем тут нравится/не нравится? Бывают инструменты, пригодные для работы и не пригодные.
A>я долго использовал MS Test для нативного С++ и никаких проблем не заметил.
Повезло.
1. До версии 2010 MSTest при использовании его для тестирования нативного кода начинал вставать в интересную позицию по превышении некоторого (небольшого) числа тестов в солюшене. Корреляции не заметили, зависимость была и о числа тест кейсов и от сложности тестируемого и включаемого в тест кода. Студия просто становилась абсолютно неюзабельной от 15 минут до бесконечности. M$ проблему подтвердили, в качестве "решения" предложили отключить IntelliSense. С отключением коего пропадал и (сюрприз!) MsTest. Затем их ответ был, то MsTest не предназначен для тестирования нативного кода и мы типа ССЗБ.
2. Простейший ассерт по двум строкам превращается в кошмар вида
3. Заумные ассерты, которые зачем-то сравнивают типы в рантайме
То есть вот это
Assert::AreEqual(12, number2);
проваливало тест кейс, даже если number2 содержал число 12 только потому, что "умный" MsTest думал, что 12 — это знаковый тип, а number2 был беззнаковым.
4. Оно медленное! Настолько медленное, что сравнивать скорость выполнения теста с тем же google test ну никак нельзя.
5. Не забываем, что тесты компилирются другим компайлером и линкуются другим линкером. В связи с этим возникали приколы, когда тестируемый код содержал объект некоего сложного типа в качестве статического мембера, а компайлер нам молвил английским голосом, что он такого не умеет
6. Тест класс — управляемый. Значит, его членами не могут быть нативные классы. Только по указателю Привет, куча врапперов на ровном месте
7. Только в 2010 студии появилась наконец возможность сразу прыгнуть на место ассерта. До этого все, что тебе давали — очень информативный "атчод" и указание на место ошибки текстом. Навигируй, типа, сам.
8. До 2010 студии MSTest пытался умничать, запуская несколько тестов на выполнение в параллель. Не отключалось никак. Какие это проблемы вызывало при тестировании кода, для которого требовались заведомо неконкурентная среда, даже описывать не буду.
9. Периодические совершенно невразумительные падения в MSTest уже после завершения тестов, не поддающиеся отладке.
10. Хоть и очень редко, но иногда возникала необходимость отладки. Mixed отладчик — та еще кака.
11. Попробуй хотя бы сделать так, чтобы тесты запускались автоматически при каждом билде, без применения паттерна "стоя и в гамаке"
Любого из этих пунктов, на самом деле, достаточно, чтобы даже не начинать рассматривать это поделие для тестирования нативного C++ кода, особенно когда есть правильные решения. Единственный плюс — интеграция со студией, но толку от нее, если честно, чуть более, чем никакого.
я использовал функции типа String^ Str(const std::string&);
L>3. Заумные ассерты, которые зачем-то сравнивают типы в рантайме L>То есть вот это
L>
L>Assert::AreEqual(12, number2);
L>
L>проваливало тест кейс, даже если number2 содержал число 12 только потому, что "умный" MsTest думал, что 12 — это знаковый тип, а number2 был беззнаковым. L>
и это правильно, ибо в С++ знаковые типы нельзя сравнивать с беззнаковыми, т.к. можно нарваться на неявный каст.
L>4. Оно медленное! Настолько медленное, что сравнивать скорость выполнения теста с тем же google test ну никак нельзя.
это да. зато UI красивый, code coverage и т.п.
L>8. До 2010 студии MSTest пытался умничать, запуская несколько тестов на выполнение в параллель. Не отключалось никак. Какие это проблемы вызывало при тестировании кода, для которого требовались заведомо неконкурентная среда, даже описывать не буду.
хз, у меня такого в 2005й не было, я нормально тестировал код с синглтонами/моностейтами
L>10. Хоть и очень редко, но иногда возникала необходимость отладки. Mixed отладчик — та еще кака.
и что с ним не так? точно такой же нормальный отладчик
L>11. Попробуй хотя бы сделать так, чтобы тесты запускались автоматически при каждом билде, без применения паттерна "стоя и в гамаке"
зачем, они же медленные
Здравствуйте, Abyx, Вы писали:
A>я использовал функции типа String^ Str(const std::string&);
Все равно ахтунг.
L>>3. Заумные ассерты, которые зачем-то сравнивают типы в рантайме L>>То есть вот это
L>>
L>>Assert::AreEqual(12, number2);
L>>
L>>проваливало тест кейс, даже если number2 содержал число 12 только потому, что "умный" MsTest думал, что 12 — это знаковый тип, а number2 был беззнаковым. L>>
A>и это правильно, ибо в С++ знаковые типы нельзя сравнивать с беззнаковыми, т.к. можно нарваться на неявный каст.
На минутотчку, в С++ такую проверку нужно проводить во время компиляции. А не в рантайме.
L>>4. Оно медленное! Настолько медленное, что сравнивать скорость выполнения теста с тем же google test ну никак нельзя. A>это да. зато UI красивый, code coverage и т.п.
Code coverage — спасибо, поржал. Он, к тому же, еще и не работает для С++ на сколько-нибудь сложном коде. А красивый ЮИ некоторых волнует примерно в отрицательную очередь.
L>>8. До 2010 студии MSTest пытался умничать, запуская несколько тестов на выполнение в параллель. Не отключалось никак. Какие это проблемы вызывало при тестировании кода, для которого требовались заведомо неконкурентная среда, даже описывать не буду. A>хз, у меня такого в 2005й не было, я нормально тестировал код с синглтонами/моностейтами
Повезло.
L>>10. Хоть и очень редко, но иногда возникала необходимость отладки. Mixed отладчик — та еще кака. A>и что с ним не так? точно такой же нормальный отладчик
Let's agree to disagree. Похоже, что я все же ходил по этим граблям в 100500 раз дольше.
L>>11. Попробуй хотя бы сделать так, чтобы тесты запускались автоматически при каждом билде, без применения паттерна "стоя и в гамаке" A>зачем, они же медленные
Здравствуйте, Аноним, Вы писали:
А>Пишу на MS VS 2010, решил добавить тесты, добавил тестовый проект, добавил тест, смотрю — там .net, а как сделать чистый с++ тест?
Я как то тоже интересовался тут уже, вот что получилось Исследование фреймворков для Юнит тестирования на C++
Здравствуйте, sharcUs, Вы писали:
А>>Пишу на MS VS 2010, решил добавить тесты, добавил тестовый проект, добавил тест, смотрю — там .net, а как сделать чистый с++ тест? U>Я как то тоже интересовался тут уже, вот что получилось Исследование фреймворков для Юнит тестирования на C++
Здравствуйте, Abyx, Вы писали:
A>сейчас лучший фреймворк — это Catch (https://github.com/philsquared/Catch) A>(всё в одном .h файле, удобный синтаксис, быстр, прост в использовании)
не пользовался, но первое впечатление после прочтения доки и взвешивания исходников
1) все в одном огромном файле (320 Кб папка include весит), ох уж эта мода все в хедеры пихать
2) макросы с простыми именами типа CHECK, REQUIRE, WHEN, GENERATE, FAIL — высока вероятность клешей с другим кодом
3) свои смарт пойнтеры, свой движок xml, свой noncopyable и много еще всяких великов =)
4) не углублялся, почему либа пропагандирует "tearDown — это зло", но под либу придется перестраивать мышление и строить юнит тесты по-другому
в целом, либа выглядит достаточно мощной:
1) куча стратегий, этим напоминает мощный gmock
2) сразу cmdline к тестам появляется
3) есть вменяемая дока
