Модульное тестирование. Файловая структура

У меня есть устаревшая кодовая база C ++ с 10-15 приложениями, и все они используют несколько компонентов.

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

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

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

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

Есть ли более/менее приемлемый способ сделать это?


Вне поля зрения, не в своем уме; если вы храните тестовые файлы вместе с файлами кода, разработчикам может быть более очевидно, что при обновлении файла кода они также должны обновлять тесты.


2

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

Что касается расположения общего тестового кода, просто организуйте свой тестовый код, если бы вы организовали код реализации.

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

Поделиться
Улучшить этот ответ
ответил 9 ноября 2009 г., 15:53 ​​
добавить комментарий |

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

Что касается расположения общего тестового кода, просто организуйте свой тестовый код, если бы вы организовали код реализации.

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


2

Я обычно организую такой код в структура файла выглядит (в простом случае) следующим образом:

  apps app1 app1module1 app2module2 app1tests app2 app2module1 app2testscomponents comp1 comp1module1 comp1module2 comp1testscommon_test_stuff  

Не существует единственно правильного способа сделать это, но, похоже, это обычная практика, при которой производственный и тестовый код разделяются и пытаются удалить вне поля зрения, вне поля зрения (упомянутая zac) одновременно.

Поделиться
Улучшить этот ответ
ответил 9 ноя 2009 в 16:25
  • 1
    app2module2 должно быть app1module2 . — Etherealone 19 фев. ’14 в 9:01
добавить комментарий |

Обычно я организую такой код в файловую структуру, которая выглядит (в простом случае) следующим образом:

  apps app1 app1module1 app2module2 app1tests app2 app2module1 app2testscomponents comp1 comp1module1 comp1module2 comp1testscommon_test_stuff  

Не существует единственного правильного способа сделать это, но это обычная практика. разделяет производственный и тестовый код и пытается одновременно устранить проблему вне поля зрения, вне памяти (упомянутая zac).


1

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

Поделиться
Улучшите это ответ
Создан 10 ноя. в 22:32
добавить комментарий |

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

Оцените статью
Botgadget.ru
Добавить комментарий