Написание модульных тестов для метода класса __init__ - PullRequest
4 голосов
/ 12 февраля 2012

Я очень новичок в модульном тестировании и написании / использовании исключений. В настоящее время я прилагаю огромные усилия, чтобы узнать о лучших практиках и интегрировать их в свои проекты. В качестве теста некоторых вещей, о которых я читал, я написал простой модуль Contracts. Ниже приводится инициализация класса контракта, который имеет несколько аргументов, которые зависят друг от друга.

Как / мне написать тест для метода init на основе его аргументных зависимостей.

Заранее спасибо!

def __init__(self, code, description ,contract_type,
             start_date ,end_date ,reminder_date, 
             customer=None, isgroup=False, vendor=None, 
             discount_perc=None):

    contract_types = ['item','vendor']
    self.code = code
    self.description = description
    self.contract_type = contract_type
    self.start_date = start_date
    self.end_date = end_date
    self.reminder_date = reminder_date
    if contract_type not in contract_types:
        raise AttributeError("Valid contract types are 'item' & 'vendor'")
    if isgroup:
        if customer:
            raise AttributeError("Group contracts should not have 'customer' passed in")
        self.is_group_contract = True
    else:
        if customer:
            self.add_customer(customer)
        else:
            raise AttributeError('Customer required for non group contracts.')
    if contract_type == 'vendor':
        if vendor and discount_perc:
            self.vendor = vendor
            self.discount_perc = discount_perc
        else:
            if not vendor:
                raise AttributeError('Vendor contracts require vendor to be passed in')
            if not discount_perc:
                raise AttributeError('Vendor contracts require discount_perc(Decimal)')

Если этот тип вопроса не подходит для SO, куда мне лучше пойти?

1 Ответ

3 голосов
/ 13 февраля 2012

Я бы обработал __init__ аналогично любому другому (не классу или статическому) методу - тестирую ожидаемый результат на основе различных комбинаций входных данных. Но в дополнение к этому я бы также проверил его на предмет возврата (или не возврата, в зависимости от ваших требований) одноэлементного объекта.
Однако можно предпочесть выделить одиночные тесты в качестве __new__ связанных тестовых случаев.

В конце концов у вас будут тесты для:

  1. Обработка недопустимых типов аргументов (пустые / непустые строки, целые числа, кортежи, символы и т. Д.).
  2. Неправильная обработка комбинаций аргументов (в вашем случае это повышенные исключения).
  3. Необязательные аргументы присутствия / отсутствия обработки (значения по умолчанию работают, пользовательские тоже, и т. Д.).
  4. Обработка допустимых комбинаций аргументов (работает положительный поток).
  5. Присутствующие / отсутствующие атрибуты результирующего объекта и их значения (скорее всего, вы полагаетесь на них в других методах).
  6. Результирующий объект, являющийся одноэлементным (или нет).
  7. ???

Другой совет: извлечение contract_types = ['item','vendor'] в атрибут class поможет в организации тестов бизнес-логики.

...