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

#Пятница18июня #срачПоФикстурам

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

Как я вижу аргументацию: «запросы в фикстуре делать нельзя, потому что:» и ссылку на какие-то правила, желательно из документации pytest.

Если вдруг почему-то этого нет в документации, есть два варианта: здравый смысл разработчиков посчитал этот пункт не принципиальным / они ошиблись! В таком ключе наверное стоить предложить пост с аргументацией почему так (можно свой / авторитетного разработчика, которого можно будет прочитать). Разумеется, этот пост должен соответствовать правилам этого сообщества и уважать все стороны.

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

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

Браво!

1)Допустим есть параметризированный(пачкой параметров декартом) тест и некая фикстура, могу ли как то затолкать красиво @pytest.mark.skipif так чтобы скипалось до того как будет выполненна фикстура?при моей реализации всегда дёрнется вначале фикстура потом будет скип.
@pytest.fixture()
def dosomething(scope="function"):
   print("text(")
   return None


class TestDebug:

   @pytest.mark.parametrize('b',[2,3])
   @pytest.mark.parametrize('a',[1,2])
   def test_one(self,a,b,dosomething):
       if a==b: pytest.skip()
       assert a!=b
2)Сейчас для каждого прогона сервиса использую регистрацию нового юзера с последующим подтверждением, думаю что уже нарегал достаточно и можно использовать ранее зареганых, как их лучше хранить ? раньше хранил в файле но что то не особо удобно, особенно когда нужно отмечать что юзер в работе или нет. Развернуть свою базу и хранить в ней пользователей+ ещё какие то данные, не будет ли это оверкил? Если норм то это лучше редис или mysql хватит с лихвой?

import pytest

@pytest.fixture()
def fix():
   if 1:
       pytest.skip()
   yield

def test(fix):
   assert 1

а в чем проблема-то?

Параметр так не проверить

import pytest

p_list = ["A", "B", "C"]

@pytest.fixture(params=p_list)
def fix(request):
   p = request.param
   if p == "A":
       pytest.skip()
   yield p

def test(fix):
   assert fix in ["B", "C"]

Так да, но тогда у нас не тест параметризован а фикстура. Полагаю такой вариант по задаче выше не подойдет

import pytest

class App:
   def __init__(self, num):
       self.num = num
       if num is 1:
           pytest.skip()

@pytest.fixture()
def fix():
   yield App

@pytest.mark.parametrize("d", [1,2,3])
def test(fix,d):
   d = fix(d)
   assert d.num in [2,3]

Почему кроме pytest и unittest другие тестовые фреймворки не используются? Это пропаганда или ж мы реально их оценили по достоинству?

Используют, специализированные всякие штук типа https://github.com/seleniumbase/SeleniumBase или https://github.com/taverntesting/tavern зачем писать велосипед, если пайтест и так отлично работает и легко плагинами расширяется, тысячи их https://docs.pytest.org/en/latest/reference/plugin_list.html

Всем, привет, подскажите как лучше всего структурировать тесты в проекте,мы используем pytest, тесты запускаем в докере, при этом есть своя библиотека которая ставится в докер как pip install, но при этом есть функции которые в эту библиотеку не хочется выносить какие-то хелперы, и вот куда их запихнуть не понятно

Может есть где можно об этом почитать?

1) Как структура проекта связана с докером? Какие требования у вас при этом накладывает рантам докера?

2) Зачем запускать тесты в докере? Они у вас привязаны к самому приложению, которое вы тестируете?

3) если у вас есть функции, которые вы не хотите выносить в библиотеку — не выносите. Заведите папку helpers / auxiliary и помещайте в неё хелперы

В проекте на работе активно продвигали: https://behave.readthedocs.io/en/stable/

Если в нескольких репах будут нужны хэлперы, то можео через git подмодули их цеплять. А вообще вопрос шибко широкий, по ситуации надо решать.

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

То есть я правильно понимаю что у вас как-то организованны тесты и это делает для вас невозможном импортировать хелпер методы?

Не совсем, сейчас пользуемся роботом, и активно хотим с него слезь, для робота хелперы лежат в той же папке что и тесты, несколько папок соответственно в каждой эти хелперы, при этом есть ситуация когда в хелперах в разных папках есть одинаковые функции ( или кейворды как они называются в робот фрейворке) при переходе на пайтест хотим от этого отказаться и сделать правильную структуру, что бы хелперы были в одном месте(например в корневой папке с тестами) все тесты лежат в папке tests и она вся копируется в контейнер так что в тестах ( даже в разных папках ) можно нормально импортировать что-то из папки test но просто импорта будут относительные, вот и хотел посмотреть как другие люди раскладывают все по папкам