Я не транслитирировал с русского языка

еще раз. функциональные тесты, интеграционные, но не юнит.

Ещё раз. Юниттесту нужен стейт. И ты либо мокаешь код и базу, либо у тебя реальная база. Чем тест становится не юнит от этого?

Юни-тест изолирован

И у него нет сайд эффектов.

Ну, база чистится между кейсами.

f(x) -> y.

Ещё раз. Юниттесту нужен стейт. И ты либо мокаешь код и базу, либо у тебя реальная база. Чем тест становится не юнит от этого?

какой стейт вообще? метод - у него есть вход, выход и внешние вызовы (точка).

какой стейт вообще? метод - у него есть вход, выход и внешние вызовы (точка).

Класс. Это в фп.

Я не транслитирировал с русского языка

с любого языка, где есть буква х :)

Класс. Это в фп.

там нет внешних вызовов

Ну просто в ФП можно все легко заюниттестить

ПОтому что нет сайдэффектов и все про дай функции аргумент, получи резалт

Если нет сайд эффектов то да.

Без этого юнит-тест уже не юнит-тест

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

но облако это сплошной сайд эффект(

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

У тебя инстанс это не одна сущность.

Ну так признайся, что пишешь системные/функциональные тесты и живи спокойно )

У него есть сети, девайсы, волюмы.

Ну лан

У него есть сети, девайсы, волюмы.

и что? это некий вход. вот этот объект - это входные данные.

Это буквоёбство уже.

вход, внешние вызовы, выход. замокал вызовы - получил юниттест;)

Ну лан

вот и молодец:)

У нас есть функциональные тесты и они ходят в облако по API.

Это уже другое)

У нас есть функциональные тесты и они ходят в облако по API.

это не функциональные тесты

У нас есть функциональные тесты и они ходят в облако по API.

это интеграционные и эксплуатационные

это интеграционные тесты

Чего это?

Это буквоёбство уже.

нет. важно понимать что ты делаешь, тогда легче понять зачем и как извлечь из этого пользу.

Боюсь это не поможет тебе ничем.

Чего это?

ну так исторически сложилось:)

Боюсь это не поможет тебе ничем.

мне то помогает;)

То тест который ходит в сервис по апи это не функциональный тест?

Чего это?

взаимодействие с внешним компонентом тестируется потому что

То тест который ходит в сервис по апи это не функциональный тест?

нет, разумеется

если апи не реальный и замоканный - тогда да

взаимодействие с внешним компонентом тестируется потому что

Что тогда функциональный?

Что тогда функциональный?

см выше

Которые не имеет взаимодействия с внешними системами?

Т.е. неИНТЕГРИРУЕТСЯ :)

Какими внешними системами

есть облако, чёрный ящик.

Облако твое епт )

Какими внешними системами

api - это внешняя система

Хотя справедливости ради, функция логин, которая ходит во внешний авторизационный сервис несет функционал “авторизация”, который хотелось бы протестить. Значит тестируя функцию логин мы делаем функциональный тест )

Лишь пасконное знание о том, что внутри эта функция идет куда-то в какой-то API делает тест интеграционным? ?

Хотя справедливости ради, функция логин, которая ходит во внешний авторизационный сервис несет функционал “авторизация”, который хотелось бы протестить. Значит тестируя функцию логин мы делаем функциональный тест )

неа

Хотя справедливости ради, функция логин, которая ходит во внешний авторизационный сервис несет функционал “авторизация”, который хотелось бы протестить. Значит тестируя функцию логин мы делаем функциональный тест )

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

это тоже интеграционный

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

именно!

Тогда это фуонкциональный? Я не понял :)

Тогда это фуонкциональный? Я не понял :)

то что я написал делает интеграционный функциональным

Тогда это фуонкциональный? Я не понял :)

да, тогда функциональный

Т.е. если я подниму у себя амазон - мой код, который создает инстансы, станет функционльным

И похер что он ходит во внешний API ? :)

Т.е. если я подниму у себя амазон - мой код, который создает инстансы, станет функционльным

типа того

Т.е. если я подниму у себя амазон - мой код, который создает инстансы, станет функционльным

не амазон, а мок для его API

Значит определение “интеграционный если ходит во внешний мир” неточно

который может вообще ничего не делать

А, это другая история

Значит определение “интеграционный если ходит во внешний мир” неточно

точно

тебе это и рассказали :)

Значит определение “интеграционный если ходит во внешний мир” неточно

в некоторолируемый тобой в рамках теста

Тогда значит если я подниму контролируемо полноценный амазон запуская тест — он станет функциональным :)

Тогда значит если я подниму контролируемо полноценный амазон запуская тест — он станет функциональным :)

типа того, да

ERROR: S client not available

Тогда значит если я подниму контролируемо полноценный амазон запуская тест — он станет функциональным :)

если ты будешь выставлять состояние твоего амазона перед каждым тестом - да

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

но если тебе для одного теста нужен весь спектр амазона - это херово написанный тест)

Ну ок, fair enough :)

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

типа того

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

ну вот, имея подготовленную фикстурами для теста БД, ты делаешь функциональный тест

Вроде пронесло на этот раз

ну вот, имея подготовленную фикстурами для теста БД, ты делаешь функциональный тест

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

на уровне базы

а функциональные тесты должны функциональность сервиса, а не базы, тестировать

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

и зафейлить тест. этой базой должен пользоваться только ты. в смысле только конкретный тестран

а функциональные тесты должны функциональность сервиса, а не базы, тестировать

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

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

и зафейлить тест. этой базой должен пользоваться только ты. в смысле только конкретный тестран

я как-то так рэйс обнаружил. именно потому что одновременный запуск тестов падал

я как-то так рэйс обнаружил. именно потому что одновременный запуск тестов падал

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

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

я скорее за то, чтобы тест максимально возможный спектр ошибок покрывал

я скорее за то, чтобы тест максимально возможный спектр ошибок покрывал

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

большой тест неудобно, потому что через пару месяцев уже сложно понять почему конкретно этот тест упал и надо заново копать

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

я скорее к тому, что нет смысла прикладывать дополнительные усилия к тому, чтобы на какой-то класс ошибок тест не реагировал

если бы упало пару юнитов, сразу всё ясно бы было

я скорее к тому, что нет смысла прикладывать дополнительные усилия к тому, чтобы на какой-то класс ошибок тест не реагировал

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

ну и для изоляции от других стори - тоже полезно.

ну т.е. это же всё про изоляцию на разных уровнях с постепенным уменьшением изоляции и увеличением интегрированности в остальные компоненты

ну и для изоляции от других стори - тоже полезно.

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

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

а если бы там был тест на паралелльное исполеннения разных наборов действий, то было бы четко понятно всё:) и при этом была бы уверенность, что дело не в коде отдельных компонентов, ну ты же понимаешь о чем я

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

т.е. тут тебе повезло найти, а могло и не повезти

а если бы там был тест на паралелльное исполеннения разных наборов действий, то было бы четко понятно всё:) и при этом была бы уверенность, что дело не в коде отдельных компонентов, ну ты же понимаешь о чем я

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

т.е. тут тебе повезло найти, а могло и не повезти

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

Коллеги, сейчас продумываем архитектуру будущего backend api. В связи с этим думаем, что можно использовать для этих целей: flask, falcon или bottle?

falcon

Т.е. сразу хардкор

если твоему приложению нужно хоть минимальное security - в докере его деплоить плохо, потому что из контейнера гораздо легче вылезти, чем из виртуалки

есть kvmtool

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

Мне понравился такой подход к процессу https://i.stack.imgur.com/mtLAM.png Тесты черного ящика с увеличентем базы юнит тестов. Это уменьшает вероятность отдать тестерам багу