TDD *

Дебаты, касающиеся программирования с применением агентов, в основном касаются подбора инструментария: какую IDE, какую модель, какой CLI использовать и т.д. Гораздо меньше внимания уделяется более интересному вопросу: а сохраняет ли в таких условиях актуальность сам подход к структурированию кода, которому нас учили, если у той штуки, которая теперь пишет код, ограничена долговременная память, а также ограничено контекстное окно? Более того, агент зачастую должен добиваться прогресса по задаче, не имея «перед глазами» всей системы.

Ниже проанализированы различные архитектуры кода: TDD (разработка через тестирование), OOP (объектно-ориентированное программирование, ООП), FP (функциональное программирование, ФП), MVC (модель-представление-контроллер), MVVM (модель-представление-модель представления), микросервисы, событийно-ориентированная архитектура, CQRS (раздельная обработка команд и запросов), гексагональная архитектура, разработка через поведение (BDD), предметно-ориентированное проектирование (DDD). Они отсортированы по показателю прикладной полезности в условиях, когда программирует не человек, а агент.

Всем привет!

Меня зовут Михаил Витик, я работаю в Лемана Тех техлидом в сервисной команде, которая поддерживает команды разработки сайта Лемана ПРО.

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

Эта задача и привела меня к идеям автоматической миграции, codemod‑трансформеров и использованию ИИ. В этой статье подробно расскажу о практическом опыте разработки автоматического мигратора кода на примере миграции с Linaria — CSS‑in‑JS решения — на CSS Modules.

О проблемах с ИИ-кодингом на Хабре написано уже много. Но хочется перейти к конструктивному подходу: да, наломать дров с ИИ легко, а вот как работать с ним наиболее профессионально?

Известные разработчики вроде Митчелла Хашимото (создателя Terraform и Ghostty) всё чаще говорят что-то в духе «вот тут уже ни строчки кода не написал вручную». При этом Хашимото — противник слопа, и он подчёркивает, что добился от ИИ качественного кода. А что помогает добиваться?

Мы в проекте Kodik подобные вопросы ощущаем особенно остро, потому что в редакторе кода с ИИ делаем… собственно, сам этот редактор кода с ИИ. Так что для нас все проблемы особенно наглядны, а их решения — особенно важны.

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

Внутренние инструменты — это странный жанр. Ты не делаешь продукт для миллиона пользователей. Ты делаешь для двадцати человек, которые будут использовать это каждый день. И если облажалась — они скажут тебе об этом лично. Прямо на созвоне. Иногда с демонстрацией экрана, где всё сломано.

Я занимаюсь этим несколько лет. Python, внутренние сервисы, утилиты, автоматизация. За это время появился довольно конкретный взгляд на то, как надо работать. Не из учебника, а через синяки.

Отвечая на этот вопрос, я разобрал следующие темы?

Где и почему агенты работают хорошо?
Где агенты делают только хуже?
Что значит "подготовить проект" к эпохе агентов
Пара тупых, но работающих советов как работать с Claude Code
Советы, что делать если ты разработчик, тимлид, владелец продукта
Как я думаю, куда всё это приведет

Продолжаем серию публикаций, посвященных истокам лондонской школы тестирования. В статье «Мокируем роли, а не объекты» (2004) авторы совершают ключевой концептуальный переход. Они переосмысливают мок-объекты: из инструмента для изоляции тестов они становятся инструментом для выявления интерфейсов, проектирования взаимодействий между объектами и создания целостной архитектуры системы.

Как можно Cursor IDE превратить в полноценную мультиагентную среду разработки, где каждый AI‑агент выполняет роль члена команды: аналитика, архитектора, планировщика или разработчика?

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

Как добиться сходимости к стабильному результату в ходе длительной самостоятельной работы команды ИИ-агентов?

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

Привет, Хабр! Про модели искусственного интеллекта сейчас не говорит только ленивый. Высказывается множество мнений и нередко они оказываются на противоположных полюсах: от полного скепсиса до убеждённости, что произошла новая научно-техническая революция. Жизненный опыт подсказывает, что истина где-то по-середине и инструмент будет полезным ровно настолько, насколько ты умеешь им пользоваться. В относительно недавнем интервью генеральный директор Microsoft Сатья Наделла заявил, что примерно 20-30 % кода в Microsoft уже сейчас генерируется ИИ и разработчикам надо будет адаптироваться. Мне тоже захотелось попробовать внедрить такого помощника в свои рабочие процессы и посмотреть, что из этого получится.

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

Как превратить автотесты в живую документацию(как техническую, так и аналитическую).

Как сделать так, чтобы они рассказывали о предметной области.

И в конце концов, проверяли, что все это работает.

Когда тест проходит с первого раза — это пугает. Стоицизм в TDD — не методология, а форма выживания.

Статья о реализации сервиса на C++ с применением TDD, DDD и событийно-ориентированной архитектуры. Проект переносит идеи из книги «Паттерны разработки на Python: TDD, DDD и событийно-ориентированная архитектура» на C++.

В области автоматического тестирования я работаю уже 15 лет. За это время я работал как в крупных компаниях, так и в небольших стартапах. Использовал различные языки программирования и технологии. Был частью разных команд — от специализированных групп разработчиков автоматического тестирования до смешанных команд, где вместе работали и разработчики, и тестировщики. За время карьеры занимал различные позиции и дорос до Senior Automation Engineer.

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

В статье про тестируемость я косвенно упоминал подход "разработка через тестирование" (TDD); сейчас же хочу поделиться переводом статьи от гуру TDD, Роберта Мартина. Он обсуждает с Марком Симаном, нужно ли при динамической типизации больше тестов. Симан утверждает, что статическая типизация исключает многие недопустимые состояния, и поэтому часть тестов становится просто ненужной. Мартин же доказывает, что тесты необходимы для проверки поведения независимо от языка. При использовании методологии TDD типизация не обеспечивает дополнительной надёжности.

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

Есть небольшая книжка написанная более 20 лет назад, переведенная на русский как «Экстремальное программирование». При обсуждении этой книжки с коллегами я часто встречал мнение, что она только про то, что надо сначала тесты писать, а потом код и больше в ней нет ничего полезного. Когда у самого добрались руки до нее, я понял, что видимо читают выжимки из статей на Хабре или просто статьи википедии, потому что там есть и паттерны проектирования, и правила написания тестов и практические примеры. А все запоминают только мантру «Утром тесты — вечером стулья код».

Кажется, про TDD давно всё известно: сперва тест — потом код — получаем покрытие. Но на деле его суть понимают неправильно — как критики, так и сторонники.

Эта статья — не инструкция и не религиозная проповедь. Это разбор заблуждений. Причём речь пойдёт не только о критиках TDD, но и о его сторонниках.

TDD часто воспринимают как способ добиться максимального покрытия или как дисциплину «писать тесты вперёд». Но настоящая цель — не в тестах, а в итеративном проектировании поведения и архитектуры.

Если вам кажется, что TDD — это занудно, медленно, не подходит к реальному коду или убивает гибкость — возможно, вы всё делали правильно.
Но с совершенно другими целями.
Именно поэтому вам не понравилось.

Разберёмся, что такое TDD на самом деле — и почему вы, скорее всего, не знаете TDD.

В ходе автоматизации тестирования пользовательских интерфейсов зачастую используется такой подход как визуальное тестирование. Он позволяет поддерживать стабильность и отсутствие ошибок в отображении страниц.  

Одним из инструментов, предоставляющих возможность автоматизации данного вида тестирования, является Playwright.

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

Все мы стремимся создавать более качественное программное обеспечение и делать это быстрее. Я считаю, что разработка через тестирование предлагает нам путь к этой цели. Все еще боитесь использовать этот подход? Тогда я приглашаю вас обсудить советы и приемы помогающие раскрыть преимущества TDD!

В мире тестирования фронтенд-приложений существует одна забавная особенность. Визуальное представление нашей программы почти всегда остается вне зоны покрытия тестами,  даже несмотря на то, что фронтенд-разработка это в первую очередь про визуал. Если посмотреть на то как пишут тесты на типичном проекте, то в основном это будут юнит-тесты проверяющие внутреннюю специфику компонентов или отдельных функций плюс какие-нибудь е2е-тесты проверяющие отдельные сценарии. Чаще всего все эти тесты полностью игнорируют визуальную составляющую, и в случаях если у вас слетели шрифты, отступы, или просто html-элемент скрыт стилями, то тесты все-равно будут зелеными.

Часто приходилось видеть тесты опосредовано проверяющие визуальное отображение html-элемента, что-то в стиле expect(elem.classList.contains("visible")).toBe(true). Говорить о надежности таких тестов конечно-же не приходится, так как изменив содержимое css-селектора стилизующий данный класс, данный тест все еще будет зелёным, несмотря на то что по факту элемент будет скрыт.

Результат от подобных тестов вполне ожидаемый. Обновили версию UI-библиотеки и на всем проекте поехала верстка? Тесты зелёные. Случайно переопределили CSS-переменную и теперь вместо приятной тщательно подобранной дизайнером гаммы цветов вы видите лишь кислотно-вырвиглазную солянку? “Бывает, надо было ручками протестировать” - скажет менеджер.

Решить данную проблему нам поможет добавление скриншот-тестирования на проект.

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

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