Телеграмм чат группы atinfo

Sergei

почему бы не создавать и удалять сущность в фикстуре?

хорошая идея

11:08пожаловаться #1

V

ну могу образно описать кодом

def test_change_value():
    resource = API.create(value1, value2)
    response = resource['id'].change(value1, "new value")
    assert response
    resource.delete_value(value1)
    resource.delete_value(value2)
    resource.delete()

11:13пожаловаться #2

V

pytest ж не выполнит после ассерта

11:14пожаловаться #3

S

Sergei in atinfo chat

ихмо я б не заморачивался и сделал бы через коллабл-фикстуру общего назначения, хотя не всем заходит философия коллабл-фикстур :)

@pytest.fixture
def create_resource():
    storage = []

    def callable(value1, value2):
        resource = Api.create(value1, value2)
        storage.append({
            "value1": value1,
            "value2": value2,
            "resource": resource })
        return resource

    yield callable

    for item in storage:
        item['resource'].delete_value(item['value1'])
        item['resource'].delete_value(item['value2'])
        item['resource'].delete()
    storage.clear()


def test_change_value(create_resource):
    resource = create_resource(my_val1, my_val2)
    response = resource['id'].change(my_val1, "new value")
    assert response

11:20пожаловаться #4

EB

https://pythontesting.net/strategy/delayed-assert/

Python Testing

Delayed assert / multiple failures per test - Python Testing

A test stops execution once it hits a failing assert statement. That's kinda the point of an assert statement, though, so that's not surprising. However,

11:22пожаловаться #5

MA

Maksim Andryushchenk... in atinfo chat

Sergei

ихмо я б не заморачивался и сделал бы через коллабл-фикстуру общего назначения, хотя не всем заходит философия коллабл-фикстур :)

@pytest.fixture
def create_resource():
    storage = []

    def callable(value1, value2):
        resource = Api.create(value1, value2)
        storage.append({
            "value1": value1,
            "value2": value2,
            "resource": resource })
        return resource

    yield callable

    for item in storage:
        item['resource'].delete_value(item['value1'])
        item['resource'].delete_value(item['value2'])
        item['resource'].delete()
    storage.clear()


def test_change_value(create_resource):
    resource = create_resource(my_val1, my_val2)
    response = resource['id'].change(my_val1, "new value")
    assert response

ну с учетом того, что фикстура должна возвращать в тест уже готовые данные, то да, не всем заходит вызывать фикстуру в тесте)

11:23пожаловаться #6

S

Sergei in atinfo chat

> фикстура должна возвращать в тест уже готовые данные

это всего лишь философия, технически можно делать так удобно, а не вешать себе вериги :)

11:24пожаловаться #7

MA

Maksim Andryushchenk... in atinfo chat

Sergei

> фикстура должна возвращать в тест уже готовые данные

это всего лишь философия, технически можно делать так удобно, а не вешать себе вериги :)

я не знал до вас человека, который бы хвалил такую практику)

11:25пожаловаться #8

V

Sergei

ихмо я б не заморачивался и сделал бы через коллабл-фикстуру общего назначения, хотя не всем заходит философия коллабл-фикстур :)

@pytest.fixture
def create_resource():
    storage = []

    def callable(value1, value2):
        resource = Api.create(value1, value2)
        storage.append({
            "value1": value1,
            "value2": value2,
            "resource": resource })
        return resource

    yield callable

    for item in storage:
        item['resource'].delete_value(item['value1'])
        item['resource'].delete_value(item['value2'])
        item['resource'].delete()
    storage.clear()


def test_change_value(create_resource):
    resource = create_resource(my_val1, my_val2)
    response = resource['id'].change(my_val1, "new value")
    assert response

ну я тоже к этому склоняюсь, просто ппц столько надо плодить этих фикстур в каждом тесте: там еще помимо ресурса надо перейти в сборник ресурсов, там попытаться изменить)

11:26пожаловаться #9

S

Sergei in atinfo chat

Maksim Andryushchenkov

я не знал до вас человека, который бы хвалил такую практику)

приятно осознавать свою уникальность 😊

11:26пожаловаться #10

V

спасибо, попробую

11:26пожаловаться #11

V

забываю частенько про фикстуры)

11:27пожаловаться #12

V

https://pythontesting.net/strategy/delayed-assert/

Evgenii B

Python Testing

Delayed assert / multiple failures per test - Python Testing

A test stops execution once it hits a failing assert statement. That's kinda the point of an assert statement, though, so that's not surprising. However,

почитаю, правда, дизайнера надо взашей гнать за блок кода)

11:31пожаловаться #13

EB

Vita

это понятно, я так и стараюсь) просто у меня перед ассертом создается сущность, потом изменяется хар-ка этой сущности, изменение проверяется на отрицательный ответ и все) как удалить сущность, которую я создал перед проверкой?

> как удалить сущность которую я создал перед проверкой?

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

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

11:31пожаловаться #14

V

Evgenii B

> как удалить сущность которую я создал перед проверкой?

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

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

то есть: фикстура подключения к БД, забираю id и тестирую, а дальше после всех тестов по API надо как-то прибраться за собой

11:33пожаловаться #15

V

у меня этих сущностей в проекте просто уйма, куча большая

11:33пожаловаться #16

V

и эти сущности могут включать в себя другие сущности

11:34пожаловаться #17

EB

можно для ORM херлпера написать логику запоминания всех сущностей, которую забираете. а потом в session scope фикстуре вызывать чистку. вместо 10 запросов типа

delete * from users where user_id = 1
delete * from users where user_id = 2
delete * from users where user_id = 3
delete * from shops where shop_id = 112
delete * from shops where shop_id = 427
и открытия конектов будет что--то типа

delete * from users where user_id in (1,2,3)
delete * from shops where shop_id in (112, 427)
...
delete * from
...
insert () into users ()

одной транзакцией. сэкономите себе пару БД коннектов при желании

11:42пожаловаться #18

V

хорошая идея, это я могу

11:44пожаловаться #19

EB

возможно под конец тестов вот такой словарь наберется

data['delete_users'] = [12, 13, 14, 15]
data['delete_shops'] = [112, 427]

for k in data:
    if k.startswith('delete'):
        verb, table = k.split('_')
        statement = f"{verb} * from {table} where id in ({",".join(data[k])})
       cursor.execute(statement)