В чем преимущество устройства с функцией и без кода разрыва?

Question

Что является преимуществом (по умолчанию) для функции-рамки без кода разрыва? Почему бы просто не вызвать функцию в начале теста?

Например, какая польза от написания:

@pytest.fixture 
def smtp(): 
    return smtplib.SMTP("smtp.gmail.com") 

def test_ehlo(smtp): 
    response, msg = smtp.ehlo() 
    # ... 

вместо того, чтобы просто:

def create_smtp(): 
    return smtplib.SMTP("smtp.gmail.com") 

def test_ehlo(): 
    smtp = create_smtp() 
    response, msg = smtp.ehlo() 
    # ... 

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

Answer 1

Что является преимуществом (по умолчанию) функции с прицелом на объектив без код разрыва? Почему бы просто не вызвать функцию в начале теста ?

Сохранение вертикального пространства.

Рассмотрим что-то вроде этого, где у вас есть более чем один прибор на тест:

import pytest 


@pytest.fixture 
def value1(): 
    return 1 

@pytest.fixture 
def value2(): 
    return 2 

@pytest.fixture 
def value3(): 
    return 3 


def test_values(value1, value2, value3): 
    assert value1 == 1 
    assert value2 == 2 
    assert value3 == 3 

Если бы мы должны были сделать это ваш путь:

def test_values(): 
    v1 = value1() 
    v2 = value2() 
    v3 = value3() 

    assert v1 == 1 
    assert v2 == 2 
    assert v3 == 3 

Это три дополнительных строк кода. Неважно, но тогда, если бы у вас было 10 тестов, которые нуждались в value1, value2 и value3? Теперь у вас есть 30 дополнительных линий вертикального пространства, в основном без причины.

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

Answer 2

У меня был аналогичный вопрос, когда я начал использовать его. Вот мой опыт:

• Светильники могут быть установлены на autouse = True, то есть автоматически запускать, что может быть невозможно при использовании встроенного вызова. Это полезно в некоторых случаях.
• Светильники добавляют читаемость, по крайней мере для меня. Глядя на подпись теста, можно выяснить, какие инициализации являются предварительным условием для данного теста. В этом смысле это также помогает сохранить тест, и его инициализация изолирована.

Answer 3

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

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