Структура хранения unit-тестов в Django(и не только)-проекте?

Question

[0LMER]

Доброго времени суток. Задался вопросом покрытия unit-тестами кода. В питоне с этим не особо работал до этого. Погуглив, не могу определиться, какой вариант правильный (сомневаюсь между двумя).
Исходя из n-ого опыта с Java, в жаба-проектах практикуется следующее:

src-|
	-main
		|-com.trolololo.foo
	-test
		|-com.trolololo.foo

То есть, есть директория с кодом, есть параллельная директория с тестами, и в ней повторяется структура основной директории.

Погуглив, нашёл такой пример для питона - тесты ложатся в пакет с основным кодом, в файл tests.py или пакет tests. Для Django видел примеры, когда в каждом аппликейшене в корне создаётся файл/пакет tests, и всё пишется туда. Но вот не совсем понимаю, как быть при более сложной структуре.

Итак, есть 2 варианта:
1. По аналогии с Java, но структура повторяется в рамках аппликейшена:

project
	|- app1
		|- services
			|- foo.py
			|- bar
				|- qwe.py
		|- models.py
		|- views.py
		|- tests
			|- test_models.py
			|- test_views.py
			|- services
					|- test_foo.py
					|- bar
						|- test_qwe.py

2. Создавать файл tests.py, либо пакет tests рядом с кодом:

project
	|- app1
		|- services
			|- foo.py
			|- foo2.py
			|- bar
				|- qwe.py
				|- test_qwe.py
			|- tests
					|- test_foo.py
					|- test_foo2.py
		|- models.py
		|- views.py
		|- tests
			|- test_models.py
			|- test_views.py

Какой вариант правильный?

Answer 1

[sim3x]

flat>>>nested

если ну совсем-совсем нужно сделать вложенность, то можно разделить большой файл на файлики и положить их в папку с названием директории и добавить пустой __init__.py

project
  |- app1
< вот такой фигни нет >
    |- services 
      |- foo.py
      |- bar
        |- qwe.py
</ вот такой фигни нет >
< для такой фигни есть commands >
    |-management
       |-commands
         |-__init__.py
         |-my_command.py
</ для такой фигни есть commands >
    |- models.py
    |- views.py
    |- tests
      |-__init__.py
      |- test_models.py
      |- test_models_supermodel.py
      |- test_views.py
      |-test_commands_my_command.py
  |-hugeapp
.....
    |- tests
       |-__init__.py
       |- test_models <<dir как питоновский пакет
          |-__init__.py           
             |- test_model1.py
             ....
             |- test_model999.py

Comments

[0LMER]

Не совсем является ответом на мой вопрос. С __init__.py в директории, чтобы распознавался, как питоно-пакет, как говорится, и ежу понятно :). Опустил их, дабы не захламлять место в схеме.

Видимо, не совсем ясен мой вопрос в рамках аппликейшенов с обычными джанго-файлами. Допустим, имеем в проекте зависимость от сторонних SOA-приложений, и их довольно много. Создаём аппликейшн с "обёртками" над различными XML/JSON API, например, "coreapp". У каждого источника имеется несколько апишек. В дальшейшем, эти обёртки будут использоваться в обычных джанго-аппликейшенах, для получения данных/проведения некоторых операций.

К примеру:

project
_____|
_____coreapp
___________|
___________source1
________________|
________________userinfo
_____________________|
_____________________maininfo.py
_____________________blablainfo.py
___________source2
________________|
________________accountsinfo
_____________________|
_____________________cardsinfo.py
_____________________depositsinfo.py
_____________________balances.py
________________operations
_____________________|
_____________________closeaccount.py
_____________________closeaccount.py
___________source3
________________|
________________something_else.py

При этом вложенность может быть ещё более глубокой

[sim3x]

0LMER:
поближе к *.py ложи тогда tests/

________________operations/
_____________________|
_____________________closeaccount.py
_____________________closeaccount.py
_____________________tests/
__________________________|
__________________________tests_closeaccount.py
__________________________tests_closeaccount.py

При рефакторинге, велика вероятность выделения в отдельный квази-независимый апп

[0LMER]

Спасибо, теперь прояснилось.

Answer 2

[Вадим Шандринов]

Наверно тут суть в реюзе приложений джанги. Если вы планируете распространять приложения (хотя бы между своими проектами) то файл/пакет tests нужно держать внутри папки приложения. Прямая аналогия с templates.
Если же тесты функциональные, то есть на поведение всего проекта и/или связки приложений, то есстествено в корне проекта пакет и там модули тестов.
Но вообще мне лично папки tests в каждой app-е загромождают проект, когда он большой - сложно окинуть взглядом всё дерево проекта. Поэтому часто делаю один пакет tests в корне проекта и внутри приблизительно повторяю дерево проекта. Мухи от котлет отдельно, так сказать.

Comments

[0LMER]

Как выше подметил sim3x, при рефакторинге, и любых переносах/изменениях в структуре придётся менять и структуру в пакете tests, что не так удобно.
Для unit-тестов размещать пакеты tests рядом с кодом довольно удобно.
Кстати, забыл написать вопрос в посте, но, возможно тут кто-то ответит - как разделить запуск unit- и интеграционных тестов? Юнит-тесты отрабатывают быстро, с моками для I/O, в отличии от остальных.

[Вадим Шандринов]

Где-то встречал тип тестов и при запустке можно указывать какой тип нужен. Вот только не вспомню где - или в стандарном UnitTest или в нойзах... вот что-то рядом https://docs.python.org/2/library/unittest.html#sk...

[Вадим Шандринов]

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

[Вадим Шандринов]

Терминологии устоявшейся нет, кмк. Напишу свое видение, может и неправильное. Юнит-тест пишется один на одну функцию/метод, модульный - на функциональность пакета/модуля, функциональные - на все приложение, интеграционные - на встройку приложения (веб-сервер, етс).
Юниты хорошо писать при TDD и только - проект живет/развивается, методы щепятся и обьединяются, на все это юниты писать - морока. Модульные помогают при рефакторе модуля - у нас ничего не сломалось. Функциональные и интеграционные - при выкатке: приложение делает то что нужно в нужном окружении.