LINUX.ORG.RU

Тестирование кода

 ,


0

3

Какой фреймворк используете? Я пока использую unittest, потому что он в стандартном питоне. Про pytest пишут, что он более конфигурируемый и проч. Вообще, я злоупотребляю фреймворками для юниттестирования, например реализуя с ними неюнит-тесты, которым нужно сохранять состояния между частями тестов, которые переходят I/O boundary и проч. unittest мне в этом смысле пришлось только один раз «обманывать», когда в пределах TestCase тестовые методы называл test_Number.*, где Number возрастал по порядку, чтобы принудить конкретный порядок исполнения методов.

А что используете вы? Есть какие-то наглядные примеры, иллюстрирующие преимущество pytest?

★★★★★

Последнее исправление: seiken (всего исправлений: 1)

неюнит-тесты, которым нужно сохранять состояния между частями тестов, которые переходят I/O boundary и проч

Какую цель преследуешь? Какие фреймворки поддерживает твой CI/CD? На каких уровнях будут тесты? Нужна ли поддержка параллельного выполнения тестов? Нужна ли параметризация? Нужны ли моки и фикстуры для сложной логики? Способен ли ты долго и муторно переписывать код под тесты, чтобы не усложнять их? Когда ты сам для себя ответишь на все эти вопросы, ответ станет очевиден.

Lordwind ★★★★★
()
Последнее исправление: Lordwind (всего исправлений: 3)
Ответ на: комментарий от Lordwind

Какую цель преследуешь?

автоматизация как можно большего количества тестов, как юнит-, так и проч.

Какие фреймворки поддерживает твой CI/CD?

CI/CD нет ещё, но скорее всего ориентироваться будем на jenkins и ко.

Нужна ли поддержка параллельного выполнения тестов?

Вот это очень желательно.

Нужна ли параметризация?

да, но я думаю, того, что Jenkins предоставляет, достаточно

Нужны ли моки и фикстуры для сложной логики?

Что такое «сложная логика»? Есть только один интерфейс, который реально надо бы мокить. В этом API простая последовательная логика запросил-получил.

Способен ли ты долго и муторно переписывать код под тесты, чтобы не усложнять их?

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

seiken ★★★★★
() автор топика

unittest мне в этом смысле пришлось только один раз «обманывать», когда в пределах TestCase тестовые методы называл test_Number.*, где Number возрастал по порядку, чтобы принудить конкретный порядок исполнения методов.

Нет чтобы как все нормальные люди просто засунуть все это в один метод)

goingUp ★★★★★
()
Ответ на: комментарий от seiken

Тогда больше похоже на pytest.

я думаю, того, что Jenkins предоставляет, достаточно

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

Что такое «сложная логика»?

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

Lordwind ★★★★★
()
Ответ на: комментарий от ya-betmen

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

seiken ★★★★★
() автор топика

Даже для самых базовых вещей у pytest удобнее синтаксис. А так например фикстуры, параметрические тесты из коробки. А ещё куча модулей, в т.ч. для асинхронщины, снапшот тестирования, hypothesis и т.д.

anonymous
()
Ответ на: комментарий от anonymous

А что еще можно делать с проектом на динамической лапше? Только портить, страдать, выбрасывать, переписывать, портить, страдать, выбрасывать, переписывать,… такова селяви.

anonymous
()