Добавление модульных тестов в существующий проект

Question

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

В моих руках «Эффективная работа с унаследованным кодом», и я использую советы из книги, когда читаю ее в проекте, над которым работаю. Проект представляет собой приложение C ++, которое состоит из нескольких библиотек, но основная часть кода скомпилирована в один исполняемый файл. Я использую googletest для добавления модульных тестов в существующий код, когда мне нужно что-то коснуться.

Моя проблема заключается в том, как мне настроить процесс сборки, чтобы я мог создавать свои модульные тесты, поскольку есть два разных исполняемых файла, которым нужно обмениваться кодом, в то время как я не могу извлечь код из моего "тестируемого" приложения в библиотеку , Прямо сейчас я сделал процесс сборки для приложения, которое содержит ссылку на модульные тесты для объектных файлов, сгенерированных в процессе сборки основного приложения, но мне это очень не нравится. Есть какие-нибудь предложения?

Answer 1

Я набросаю структуру make-файла, которую вы можете использовать:

all: tests executables

run-tests: tests
    <commands to run the test suite>

executables: <file list>
    <commands to build the files>

tests: unit-test1 unit-test2 etc

unit-test1: ,files that are required for your unit-test1>
    <commands to build unit-test1>

Это примерно то, что я делаю, как единственный разработчик моего проекта

Answer 2

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

Answer 3

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

Если вам нужно связать другие объектные файлы, которые не тестируются, то это признак зависимостей, которые необходимо разорвать, для которых у вас есть идеальная книга. У нас есть похожие проблемы, и мы используем систему, подобную той, которую предложил Vlion

Answer 4

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

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

Если вы получили ошибку, тесты прервут процесс сборки в нужном месте.

Answer 5

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

Спасибо вам и удачи в тестировании.