Мне нужен инструмент для автоматизированного модульного тестирования программ на C++ (конкретно — под MSVC ++ 6.0). Я посмотрел NUnit 2.2 — он бы мне подошёл, но:
мой C++ код имеет много мест, которые компилируются только MSVC ++ 6.0, а уже MS VС++.NET не пропускаются. А, как я понимаю, MSVC ++ 6.0 для NUnit 2.2 не подойдёт.
Так что нужно что-то другое, но с теми же возможностями:
— возможность создавать отдельные модули (в виде DLL) и запускать сразу НЕСКОЛЬКО модулей вместе, как это делает NUnit 2.2;
— запуск из команднйо строки и генерацию текстового отчёта.
Здравствуйте, Glenn, Вы писали:
G>Здравствуйте, ioni, Вы писали:
I>>а cppUnit не подходит I>>http://sourceforge.net/projects/cppunit
G>А там точно есть возможность делать НЕЗАВИСИМЫЕ модули (в виде DLL) и запускать их ВСЕ СРАЗУ (целым набором) с выдачей единого отчёта?
Здравствуйте, <Аноним>, Вы писали:
I>>может проще скачать и попробовать
А>Проще — да. Но РАЦИОНАЛЬНЕЕ — свалить часть работы на других; и только потом включиться саммому :=)
Т.е. "я за вас мою работу делать не буду!"
Re[6]: что-то вроде NUnit 2.2, но для MSCV++ 6.0
От:
Аноним
Дата:
25.07.05 10:30
Оценка:
Здравствуйте, nzeemin, Вы писали:
N>Здравствуйте, <Аноним>, Вы писали:
I>>>может проще скачать и попробовать
А>>Проще — да. Но РАЦИОНАЛЬНЕЕ — свалить часть работы на других; и только потом включиться саммому :=)
N>Т.е. "я за вас мою работу делать не буду!"
Разобравшись с CppUnit-ом установил, что он не подходит мне вот по какой причине: созданные на его базе тесты НЕ работают (валятся) если какие-то из написанных мной тестовых DLL-ей используют СВОЮ (статичиски прикомпонованную) версию C++ Runtime Library (CRT). Ситуация вообще-то редкая, но вот именно у меня она случилась 9мне НУЖНО по условию задачи использовать именно статически прикомпонованные CRT).
Причина этих падений CppUnit-а в том, что там обмен между тестовым можулем и самой CppUnit.dll осуществляется с использованием классов, экспортированных из CppUnit.dll (слово __dllexport). Такая схема является потенциально опасной и приводит к сбоям. Вот представим: мой тестовый модуль создал объект класса, импортированного из CppUnit.dll. Сам CppUnit.dll использует ДИНАМИЧЕСКУЮ версию CRT; следовательно, и код этого класса использует её же. Но код данного моего тестового модуля, в котором я использую объект этого импортированного класса, использует СТАТИЧЕСКУЮ версию CRT. У этой версии СВОЙ heap. Такая ситуация приводит к случаям, когда пытаемся освободить объект, используя для этого декриптор heap-а ДРУГОЙ CRT. В результате — падение.
Как я понял, CppUnit вообще на такое не рассчитывался и его разработчики об этом не думали. Изюавить от этой ситуации мог бы интерфейс между тестовым модулем и ядром test framework-а, НЕ использующий таких вот экспортированный классов. То есть — COM-подобный интерфейс.
Вопрос: не знает ли кто продукта подобного CppUnit-у, нов котором данная проблема не случалась бы?
Здравствуйте, ioni, Вы писали:
I>Здравствуйте, Glenn, Вы писали:
I>а если попробовать собрать cppUnit с твоей версией crt да еще со статической компоновкой?
будет точно то же самое (проверял) — всё равно ведь будут присутствовать ДВЕ ОТДЕЛЬНЫЕ версии CRT.
