Телеграм канал «QA-Логия»

Недавно решил разобраться с фичей skills в Claude Code. Если коротко, это инструмент, который пришел на смену кастомным slash-командам и значительно расширяет их возможности.

В процессе изучения нашел несколько интересных моментов:

- Генерация маркетингового контента:
Анализирует приложение и помогает писать посты для продвижения, например для Хабра.

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

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

- Улучшение фронтенда:
Помогает привести сгенерированный нейросетью фронтенд в более аккуратный и продакшен-подобный вид. Так как фронт это мое основное направление то эта штука это то что я протестил чуть больше. Разница в качестве генерируемого кода мне показалась довольно заметной.

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

👉 Геныч.

🤣 Что за дурацкие простые задачки?

💥 xCode Journal

🔍 Как отслеживать перформанс-метрики приложения и выкатывать только позитивные изменения

В статье рассказывается, почему производительность приложений важна, какие метрики важны для анализа, и как Авито проверяет перформанс через A/B‑тесты. Полезно для тех, кто хочет начать следить за скоростью.

Читать...

🖥 Anthropic выпустили Code Review

Систему, которую в компании запускают почти на каждом PR. За последний год объём кода на инженера в Anthropic вырос примерно на 200%. При такой скорости неудивительно, что ревью стало узким местом.

Теперь Code Review автоматически проверяет PR: несколько ИИ-агентов параллельно ищут баги, перепроверяют результаты и ранжируют проблемы по серьёзности. Причем чем более объемным и сложным будет PR — тем больше агентов туда пойдет работать.

✖️ xCode Journal

⚙️ Основы разработки для автоматизации тестирования

Автоматизация тестирования требует надёжных скриптов и минимизации зависимости от UI. В статье разбираем пирамиду тестирования Майка Кона: юнит‑тесты, сервисные проверки и UI‑тесты.

Читать...

Монолитные автотесты: проблема и пути решения

1. Сложность поддержки и масштабирования

Монолитные тестовые системы часто становятся громоздкими и трудными в обслуживании. При увеличении объема кода сложность внесения изменений возрастает, что приводит к снижению эффективности тестирования. В статье на Хабре отмечается, что разделение автотестов по принципу "один репозиторий содержит тесты на один API" позволяет изолировать зависимости и ускорить процессы разработки. Подробнее в статье на Хабре.

2. Нестабильность и ненадежность тестов

Монолитные автотесты подвержены нестабильности, что приводит к ложным срабатываниям и снижению доверия к результатам тестирования. В статье на Хабре подчеркивается важность использования моков для изоляции тестов и повышения их стабильности. Читать далее на Хабре.

3. Замедление процессов CI/CD

Крупные монолитные тестовые наборы увеличивают время выполнения тестов, что замедляет процессы непрерывной интеграции и доставки (CI/CD). Разделение тестов на более мелкие, независимые модули позволяет ускорить их выполнение и повысить эффективность CI/CD. Узнать больше на Хабре.

4. Ограниченная гибкость и адаптивность

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

❗️Заключение

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

Источники:

1. Статья на Хабре о разделении автотестов.
2. Статья на Хабре об использовании моков.