модульное тестирование — восстановление состояний объектов при переполнении стека

Я хочу использовать автоматический подход к созданию модульных тестов в C ++ с помощью LLVM. Подход должен автоматически получать состояния конкретных объектов во время динамического анализа тестируемого приложения (AUT). После того, как данные были записаны, я хочу написать тест. Здесь тест должен реконструировать объекты с записанными тестовыми данными в качестве установки перед выполнением тестируемого метода / кода.

Под состояниями объекта я подразумеваю все значения переменных-членов объекта, включая
ссылки на другие объекты (для которых мне также необходимо приобрести и
реконструировать все состояние объекта). Однако, поскольку ВСЕ значения членов включают значения переменных частного члена, я столкнулся с проблемой. Из того, что я узнал, нет способа получить доступ к закрытым переменным-членам в C ++. То есть, если рассматриваемый тип объекта не является другом любого из «типов моего объекта» или не предоставляет функции прямого доступа своим закрытым членам.

На самом деле, я могу решить эту проблему для типов, которые были объявлены в исходном коде AUT. Здесь я могу использовать LLVM для инструментов типов с необходимым кодом во время компиляции. Однако я не могу сделать это для ссылочных типов из предварительно скомпилированных библиотек, которые использует AUT.

Отсюда мой вопрос: знаете ли вы, как я могу записывать и восстанавливать полные состояния произвольных объектов, для которых у меня нет исходного кода? Может ли помочь прямое копирование памяти?

Поскольку мой подход на самом деле является генерацией базовых (автоматических) модульных тестов, я уверен, что должен быть способ реализовать это в C ++. В конце концов, такие генераторы уже реализованы в Java и C #.

2

Решение

C ++ не предназначен для этого, потому что в базовом языке нет самоанализа и сериализации объектов.
Конечно, вы можете реализовать это самостоятельно, но, возможно, вам следует использовать фреймворк, который может вам помочь, такой как protobuf или Qt.
Главное, это будут оказать большое влияние на код, который вы собираетесь тестировать.
Я рекомендую использовать другой подход, возможно, написание кода, который фактически устанавливает состояния объектов в ваших тестах, это будет гораздо менее навязчивым.

0

Другие решения


По вопросам рекламы [email protected]