Иногда смотрю на то, как меняются инструменты в разработке, и ловлю себя на мысли, что никакой логики в этом нет, а есть только мода, усталость и всеобщее желание делать проще. Одни вещи исчезают, потому что были плохими, другие, потому что появились инструменты лучше, а третьи просто потому, что сообщество внезапно решило, что “так теперь правильно”. История pytest как раз из этой последней категории. Он не ворвался в мир Python как революция, не ломал старые подходы, не обещал спасения, он просто появился в тот момент, когда разработчики окончательно устали от тяжеловесности unittest и захотели, чего‑то более простого.

С этого желания всё и началось, сначала небольшие проекты, потом фреймворки, потом компании, а потом и вся экосистема Python вдруг оказалась на pytest, будто так было всегда. Но если копнуть, становится ясно, что это не просто победа удобства над традицией, это отражение того, как менялось само сообщество, и почему unittest, несмотря на свою “старость”, всё ещё держит позиции и молча наблюдает за происходящим. Если попытаться объяснить популярность pytest сухими фактами, получится скучная лекция, мол, синтаксис проще, фикстуры удобнее, плагины мощнее. Но это всё на самом деле лишь поверхность. Настоящая причина того, что pytest стал стандартом, в том, как изменилось Python‑сообщество.

Когда‑то Python был языком для энтузиастов, скриптов, научных задач и людей, которые писали код для себя. В те времена unittest казался нормальным, он был строгий, структурированный, похожий на то, что было в Java и C#. Он был частью стандартной библиотеки, а значит официальным, правильным и надёжным. Никто особенно не жаловался, потому что тесты писали редко, а если и писали, то в корпоративных проектах, где всё равно требовали отчёты, классы, формальности и прочие ритуалы. Но потом Python внезапно стал языком веба, микросервисов, стартапов, ML‑прототипов, быстрых экспериментов, и мир вокруг менялся быстрее, чем стандартная библиотека успевала моргнуть. Разработчики начали писать код быстрее, гибче, свободнее, и unittest стал выглядеть как дед, который приходит на тусовку с галстуком‑бабочкой и пытается объяснить молодёжи, что “раньше всё было по правилам”. Вот именно в этот момент появился pytest, но не как замена, а как естественный ответ на происходящее.

Pytest стал популярным не потому, что он лучше, а потому что он совпал с эпохой. Он говорил на том же языке, что и современные разработчики, простом, прямом, без лишних церемоний. Он позволял писать тесты так же, как пишется сам Python‑код, свободно но функционально, без классов, без наследования, без ощущения, что ты опять должен провести ритуал с бубном. Это совпадение оказалось настолько точным, что люди начали мигрировать на pytest не потому, что unittest канул в небытие, а потому что изменились подходы в разработке. Статья в принципе о том, что unittest не пережиток прошлого, unittest никуда не делся. Он продолжает жить, и не просто жить, а занимать своё место, пусть незаметное, но фундаментальное. Его знают, его уважают, его используют там, где нужна предсказуемость, строгая структура и уверенность, что через десять лет всё будет работать так же, как сегодня.

Да, unittest стоит знать. Знать не потому, что ты будешь на нём писать, а потому что он объясняет, откуда вообще взялись тесты в Python, почему они устроены так, как устроены, и почему pytest выглядит именно как протест против этой структуры. Знание unittest помогает понять эту эволюции. Это как знать, как выглядели первые мобильные телефоны, ты ими пользоваться не будешь, но понимание истории помогает лучше понимать основы. Думаю, что pytest победил не unittest, а время. unittest же остался как напоминание о том, с чего всё начиналось, и почему мы больше не хотим туда возвращаться, хотя понимать его всё равно нужно, как понимать типизацию прежде, чем пытаться писать классы. Как считаешь?