Писать или не писать тесты — выбор очевидный. Конечно, писать. Но если проект масштабный, одних unit‑тестов будет недостаточно: они бессильны на границах модулей, в интеграциях и пользовательских сценариях, а значит в этих местах будут пролезать баги. Такой код будет сложно поддерживать, вносить в него изменения и получать ожидаемый результат.

В статье поговорим про разные стратегии тестирования под разные риски и кейсы. Поднимемся над привычными unit‑тестами и заглянем, что там есть еще. Спойлер: а еще там workflow‑, integration‑, property‑based‑ и resilience‑тесты.

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

Чтобы такого не происходило, у нас в Mindbox есть гайд по разработке. В статье делимся принципами из гайда — пригодится всем, кто хочет, чтобы код в проекте был поддерживаемым и приносил пользу, а не боль.