Python, импортирующие модули для тестирования

Question

Мне очень сложно создать простой тест.

Моя структура проекта выглядит следующим образом:

project: 
    models: 
     __init__.py 
     user.py 
     constants.py 
     test: 
     test.py 

Я хочу проверить user.py ру работает test.py.

user.py

from sqlalchemy import Column, Integer, String, Text 
from sqlalchemy.orm import relationship 
from .models.constants import * 
from .models import Base 

class User(Base): 
    __tablename__ = 'users' 

    uid = Column(Integer, primary_key=True, autoincrement=True) 
    name = Column(String, nullable=False) 
    email = Column(String, nullable=False) 
    picPath = Column(String, unique=True) 
    description = Column(Text) 

    def __repr__(self): 
     return "<User(uid=%s, name=%s)>" %(self.uid, self.name) 

test.py

from ..user import User, Group 

def _TestUser(): 
    TEST_DB_URI = "postgresql://project:password@localhost:5432/projectdbtest" 
    SessionMaker = sessionmaker() 
    engine = create_engine(TEST_DB_URI) 
    SessionMaker.configure(bind=engine) 

    session = SessionMaker() 
    user = User("test subject", "testsubject@gmail.com", "~/testsubject.jpg", "I am a test subject") 
    session.add(user) 
    session.commit() 

Однако, я получаю следующее сообщение об ошибке, когда я бегу python3 -m test.py:

SystemError: родительский модуль '' не загружен, не может произвести относительный импорт

Я думаю, что, возможно, мне придется dd пакет модулей к пути python?

Answer 1

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

Всегда тест от корня проекта

Изначально я предполагал, мои тестовые случаи должны быть доступны из любого каталога.

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

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

Keep тест каталог отдельно от пакета кода

Mixing кода производства с тестовым кодом кажется логичным, но вскоре становится грязным.

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

Преимуществами являются:

• тесты «близко», чтобы выбрать (смотрите следующую часть, касающуюся py.test) и использовать вручную или от других инструментов, как tox.
• не нужно искать тестовые каталоги где-то в каталогах пакетов, они просто живут в отдельном месте
• чувствовать себя уверенно экспериментировать с тестами - потому что вы отсутствуете из основного кода.

Примечание: старайтесь использовать всегда имя tests, не используйте test. Сохранение этого простого правила упростит вашу работу, так как вы всегда будете знать настоящее имя тестового каталога.

Использование pytest рамках тестирования

Есть несколько рамок тестирования (unittest, nose, nose2, pytest) и на самом деле все это обеспечивает основы вам.

Во всяком случае, я нашел pytest (с py.test команда) является реальное удовольствие использовать для нескольких причин:

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

Избегайте использование __init__.py в тестовой ванной реже

См Choosing a test layout/import rules для объяснения и следовать советам, чтобы избегать использования __init__.py.

Короче говоря, все будет проще.

Обратите внимание, что другие подходы тоже будут работать и не ошибаются - я просто хотел поделиться тем, что хорошо работает для меня.