TGViewer
Channel Public Channel
PRO автотесты

PRO автотесты

@test_automation_pro

Subscribers
311
Photos
11
Videos
0
Links
15
Recent Posts 19 shown
Post #29 232
Генератор стабов из TypeScript-типов

Когда тестируешь компонент — надо откуда-то взять данные, которые он показывает. Обычно это ответ сервера: объект с десятками полей. Для теста из них важны два-три поля, а заполнить нужно все, иначе либо сборка упадёт, либо компонент выдаст ошибку при запуске теста. Если задавать данные в коде, то будет простыня значений, в которой трудно понять, какие поля важны для теста, а какие — просто чтобы тип сошёлся.

Для решения этой проблемы я сделал инструмент — ts-stub-gen. Он читает типы проекта и для каждого типа генерирует хелпер — функцию, которая возвращает объект со всеми заполненными полями. При вызове можно передать параметром набор значений, которые важны для этого конкретного теста, а остальные поля заполняются значениями по умолчанию.

Было:
const response: Response = {
requestId: "r-1",
status: "ok",
pagination: { page: 1, perPage: 20, total: 1 },
account: { id: "42", balance: 100, tags: [], createdAt: new Date(0) },
};


Стало:
const response = GetStubResponse({
account: GetStubAccount({ balance: 100 }),
});


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

Мы уже внедрили ts-stub-gen в своём проекте и, благодаря этому, удалили файлы с кодом создания тестовых данных — их приходилось править после каждого изменения модели.

Вы можете поставить ts-stub-gen в свой проект и попробовать, как он работает:
npm install -D ts-stub-gen
# создать ts-stub-gen.config.json: откуда брать типы, куда положить хелперы
npx ts-stub-gen


Документация: https://dima117.github.io/ts-stub-gen
dima117.github.io ts-stub-gen Стабы данных для тестов из типов TypeScript
  • 🔥 16
  • 👍 2
  • ❤ 1
  • 💯 1
Post #28 366
  • 🔥 19
  • ❤‍🔥 7
  • 💘 2
Post #27 368
В субботу я читал лекцию об автотестах в Школе разработки интерфейсов Яндекса. В этом году я полностью переработал материал и собрал лекцию с нуля.

Организаторы прислали инфографику с отзывами студентов — фидбек очень положительный!

Рад, что лекция оказалась полезной. Запрос на рассказ о написании тестов с помощью ИИ — принят, добавлю эту тему в будущие лекции.
  • 🔥 20
  • ❤ 5
  • 👍 2
Post #26 596
Post #25 644
Приёмы_рефакторинга_для_тестируемости.pdf339.3 KB
Скоро начало 3 квартала и в Яндекс 360 идет квартальное планирование. Два сервиса запланировали в Q3 внедрение модульного тестирования и попросили описание типового рефакторинга для уменьшения связности компонентов приложения.

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

Если возникнут вопросы или фидбек — буду рад обсудить в комментариях.
  • 🔥 9
  • ❤ 3
Post #23 665
Еще один случай с участием #ии

Мы сегодня обнаружили тест, который проходил успешно, но не проверял то, что указано в заголовке. Посмотрели историю VCS. Оказалось, изменения сделал ИИ, а разработчики не заметили их на код ревью из-за большого размера PR.

Код на скриншоте должен проверять, что после применения фильтра в списке остаются записи, которые соответствуют его условиям. После обновления ui-kit изменилась структура вёрстки и перестал работать контрол выбора условий фильтра. Фильтрация в тесте перестала срабатывать и в списке начали отображаться все имеющиеся элементы. Тест стал падать.

ИИ увидел, что тест падает и, вместо того, чтобы починить причину, исправил условие проверки.


Мы использовали обычный процесс разработки и появилась ошибка, о которой мы не узнали. Мы, конечно, добавим в системный промпт ограничение для обработки подобных ситуаций и с помощью ИИ поищем другие тесты с некорректными проверками. Но, технически, могут возникнуть и другие ситуации, в другом контексте, в которых ИИ затупит и в проекте появятся скрытые ошибки. Это немного напрягает, пока не решили, что с этим делать.
  • 🤔 7
  • 😁 6
  • 👏 3
  • 😱 3
  • ❤ 1
  • 🤣 1
Post #22 526
  • 🔥 22
  • 😎 6
  • ❤‍🔥 3
Post #21 664
Только-что внезапно осознал крутой профит от полного покрытия автотестами — они дают возможность делать сложные рефакторинги при помощи ИИ.

У нас в команде есть регулярные "архитектурные встречи" и только-что на одной из них мы попросили нейросеть выполнить рефакторинг. Нейросеть переписала большой кусок легаси. Мы запустили тесты, они показали несколько мелких ошибок. Мы их поправили и все тесты прошли!

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

Задача, на которую мы планировали 3 дня, сошлась за два часа! Я очень впечатлен! 🌟
  • 🔥 26
  • ❤ 6
Post #20 681
Мне написали из программного комитета HolyJS и предложили повторить воркшоп по автотестам на конференции в мае. Осенью был хороший фидбек от участников, но сам воркшоп был без записи и количество мест было ограничено. Кажется, неплохая идея — повторить его еще раз.

Уже добавили в программу: https://holyjs.ru/talks/85f07cd2a65844f391044d6a97e34c2a/
  • 👍 16
  • ❤ 9
  • 🔥 6
Post #19 689
Привет! Наверно, вы заметили, что в этом канале два месяца не было новых постов. Дело в том, что в конце прошлого года у меня появилось хобби — разработка сюжетной 2D игры на движке Godot (на C#). Я никогда раньше не разрабатывал игры. Оказалось, это дивный новый мир с кучей нюансов и подводных камней. На это сейчас уходит много свободного времени, которое раньше тратил на написание постов в этом канале.

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

Я сделал еще один канал, чтобы писать туда апдейты статуса игры. Если интересно понаблюдать за разработкой, то заходите: https://t.me/+8LgS9kW40f83ZTcy
Godot Engine Godot Engine - Free and open source 2D and 3D game engine Godot provides a huge set of common tools, so you can just focus on making your game without reinventing the wheel.
  • ❤ 15
  • 👍 5
  • 🔥 1
Post #18 710
С Новым годом вас! 🎉

Пусть в следующем году вся работа приносит удовольствие!

Пусть в работе будет больше автоматизации и меньше рутины!

Пусть в команде будет взаимопонимание: идеи пусть встречают поддержку, а обратная связь — только конструктивная!
  • 🎉 22
  • 🎄 13
  • 🔥 5
Post #17 2.02K
Сейчас был созвон, на котором обсудили вопросы, не поместившиеся в мастер-класс на HolyJS. Кто-то из учасников нажал запись и она сохранилась на его Яндекс Диск. Тот, кто это сделал, поделитесь, пожалуйста, записью.

UPD: запись нашлась, доступна на Яндекс Диске
Яндекс Диск 2025-11-24_190704_про автотесты.webm Посмотреть и скачать с Яндекс Диска
  • ❤ 9
  • 🔥 6
Post #16 1.91K
Вчера провёл мастер-класс по модульным тестам на HolyJS. На учебном проекте разобрали подходы к написанию тестов и рефакторингу, чтобы модульные тесты проверяли функциональные требования, а не только API внутренних компонентов.

Два часа лайвкодинга пролетели незаметно. К сожалению, успел рассказать около 70% от запланированного, но зато обсудили много вопросов из зала. В конце голова кипела от большого количества информации, но кажется, многим участникам понравилось и было полезно.

Весь код с мастер‑класса выложен на GitHub; в ключевых местах добавил комментарии. Если появятся вопросы, пишите мне — можно прямо в комментариях к этому посту.

Хочу рассказать оставшуюся часть материала. Предлагаю созвониться в ближайший понедельник вечером: покажу несколько приёмов, как сделать код автотестов проще для восприятия. Приходите!

Дата: понедельник, 24 ноября
Время: 19:00 мск
Ссылка: https://telemost.yandex.ru/j/4102903660
  • 🔥 28
  • ❤ 13
  • 👏 1
Post #15 733
Уже в этот четверг я проведу мастер‑класс по модульному тестированию на HolyJS 2025 Autumn. Поговорим о том, что именно стоит тестировать в реальных проектах и зачем. Я покажу практические приёмы, которые вы сможете перенести в свой код.

Формат мастер‑класса — лайв‑кодинг в духе парного программирования. Мы возьмём несколько сценариев, характерных для реальных проектов, напишем для них автотесты и проведём рефакторинг, чтобы сделать код более удобным для тестирования.

Для демонстрации я подготовил приложение‑тренажёр с реалистичной предметной областью (интернет‑магазин). Код написан в упрощённом учебном стиле, чтобы сфокусироваться на сути: тестах и рефакторинге. Стек: TypeScript + React, есть SSR, используются популярные библиотеки React Router, React Query и Redux Toolkit.

Проект будет полезен даже тем, кто не идёт на мастер‑класс. Попробуйте клонировать репозиторий, запустить приложение локально и покрыть автотестами функциональные требования, описанные в README.

https://github.com/dima117/example-store#readme

Если появятся вопросы — пишите в комментариях к этому посту или в личные сообщения. Буду рад обсудить ваши кейсы и идеи!
HolyJS 2025 Autumn. JavaScript-конференция: от фронтенда до бэкенда Как писать полезные unit-тесты для веб-интерфейса | Доклад на HolyJS 2025 Autumn Вы узнаете, как сделать свой проект тестируемым, и познаете дзен unit-тестов. Научитесь писать тесты, которые проверяют продуктовые сценарии, выполняются за секунды и не падают, если приложение не сломано.
  • 🔥 21
  • ❤ 7
  • 👍 6
Post #14 1.21K
В продолжение темы о предупреждениях в тестах расскажу еще про сообщения вида:

An update to <название_компонента> inside a test was not wrapped in act


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

Но дело в том, что при запуске тестов мы продолжали видеть предупреждения "... not wrapped in act", хотя на тот момент в проекте уже использовалась testing-library и обрабатывались краевые случаи, описанные в статьях. Предупреждений было очень много, несколько сотен 😱

Мы стали копать дальше и нашли обсуждение на GitHub. Оказалось, что логика обработки этой ситуации в @testing-library завязана на статический объект, создаваемый кодом библиотеки @testing-library/dom. Если в проекте содержится несколько разных версий этой библиотеки (например, установлены как транзитивные зависимости), то может оказаться, что разные вызовы API обращаются к разным экземплярам этого объекта и из-за этого они не понимают, что действие уже обернуто в act.

В конфиге Jest мы настроили маппинг, чтобы при сборке все импорты из @testing-library/dom разрешались в одну версию библиотеки (в конкретную папку в node_modules на верхнем уровне).

  moduleNameMapper: {
'^@testing-library/dom$': `<rootDir>/node_modules/@testing-library/dom`
}


Это помогло, предупреждения исчезли. Консольный вывод модульных тестов теперь короткий и понятный 😎
  • 👍 12
  • 🔥 5
  • 😎 5
Post #13
Channel photo updated
Post #11 874
Во время прогона наших модульных тестов в консоли отображалось много предупреждений (сообщений, которые выводятся через console.error или console.warn). В основном это были предупреждения React, например об устаревших API, которые используются в компонентах.

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

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

Но мы нашли еще одно решение. Пакет vitest-fail-on-console позволяет управлять выводом предупреждений в тестах. Для jest есть похожий пакет jest-fail-on-console.

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

Теперь при запуске наших тестов в консоль не выводится ничего лишнего и сообщения об ошибках сразу видны.
  • 🔥 15
  • ❤ 7
Post #10 715
Вчера на работе была встреча с QA, на которой обсуждали терминологию и подходы к автоматизации тестирования. Руководитель QA поделился интересной статьей Shift testing left with unit tests от Microsoft.

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

Авторы статьи предлагают разделить тесты на слои на основе количества зависимостей и времени выполнения. Лёгкие и быстрые тесты нужно выполнять как можно раньше и чаще, например, на машине разработчика или при изменениях в pull request. Тяжелые медленные тесты можно выполнять позже и реже, например, после мержа изменений в основную ветку и при релизах.

В статье выделены уровни автотестов:
L1 — модульные тесты, которые зависят только от кода
L2 — функциональные тесты, которые взаимодействуют с зависимостями вне кода (например, БД, файловая система)
L3 — тесты, проверяющие задеплоенный сервис (при обращении к соседним сервисам использовать заглушки)
L4 — тесты, максимально приближенные к контексту, в котором находится пользователь

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

Этот подход близок к тому, что мы делаем в своих проектах внутри Яндекс. Круто, что статья коротко, но при этом понятно объясняет ключевые идеи.

По ссылке вы можете прочитать полный текст статьи https://learn.microsoft.com/en-us/devops/develop/shift-left-make-testing-fast-reliable
Docs Shift testing left with unit tests - Azure DevOps Learn about shift left, unit tests, and other DevOps test principles and strategies that lead to better code quality and faster time to production.
  • ❤ 3
  • 👍 3
  • 💯 2
Post #9 608
В мире интеграционных тестов есть крутой паттерн Page Object. Суть его в том, что вы обращаетесь к тестируемому приложению не напрямую из кода тестов, а делаете слой абстракции — обертку, которая содержит логику работы с элементами вашего интерфейса. Вы сможете переиспользовать логику, помещенную в обертке, во всех местах, где она нужна, а код тестов станет проще и понятнее.

Например, представьте, что у вас есть тест на Playwright, в котором написано:

// кликаем по ссылке "Get started"
await page.getByRole('link', { name: 'Get started' }).click();


Вы можете сделать PageObject

class HomePage {
// в конструкторе получаем page,
// через который происходит
// взаимодействие с браузером
constructor(private page) {}

// свойство для доступа к ссылке "Get started"
get GetStarted() {
return this.page.getByRole('link', { name: 'Get started' });
}
}


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

const homePage = new HomePage(page);

await homePage.GetStarted.click();


Теперь во всех местах, где вам нужно кликнуть по ссылке "Get started", вам не нужно заново писать код, который обращается к ней. Вы можете просто создать Page Object и обратиться к его свойству. Очень удобно!

А самое замечательное — этот подход применим и для модульных тестов. Отличие в том, что код интеграционных тестов выполняется вне браузера и отправляет команды через специальный API (Selenium или CDP), а код модульных тестов выполняется в одном контексте с кодом тестируемого интерфейса и может напрямую оперировать DOM элементами.

class HomePage {
constructor(private page: Element) {}

get GetStarted() {
// используем функцию getByRole из библиотеки @testing-library/dom
return getByRole(this.page, 'link', { name: 'Get started' });
}
}


Я написал небольшую библиотеку jsdom-fragments. Она содержит API, с помощью которого можно легко описывать Page Objects для модульных тестов в jsdom. Похожий API мы используем в Яндексе уже 4 года и это очень удобно. Теперь вы тоже можете попробовать Page Objects в своих модульных тестах!

https://www.npmjs.com/package/jsdom-fragments
  • 👍 12
  • 👏 3
Older posts →

About this channel

How can I read @test_automation_pro without a Telegram account?
TGViewer shows the public web preview Telegram publishes for PRO автотесты: recent posts, photos, videos and the subscriber count, with no app, login or account.
How many subscribers does PRO автотесты have?
PRO автотесты (@test_automation_pro) has 311 subscribers on Telegram, refreshed roughly every 30 minutes.
Does PRO автотесты know I viewed it here?
No. Public channel previews carry no viewer identity, and TGViewer has no accounts or tracking of what you look up.
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →