Где я должен поставить свой тестовый код в отношении кода, который он тестирует?

Question

Два очевидных места, о которых я могу думать, были бы своего рода «тестовой» папкой рядом с кодом, над которым я работаю. Так что-то вроде:

\project-code 
    \my-feature 
     \production-code 
     \testing 
      ***my tests*** 
    \co-workers-feature 
     \production-code 
     \testing 

Или я мог бы разделить тестовый код на совершенно отдельную иерархию. Так что-то вроде:

\project-code 
    \my-feature 
    \co-workers-feature 
\testing-project-code 
    \my-feature 
     ***my tests*** 
    \co-workers-feature 

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

Answer 1

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

Вот связанный с этим вопрос:

Do you put unit tests in same project or another project?

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

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