Тема: testing
-
Бенчмаркинг изменения: прогрев, повторы, разброс и что указывать в отчёте
Сравнение по времени выполнения — это результат только тогда, когда он устойчив к шуму: зафиксируйте нагрузку, отбросьте прогревочные прогоны, чередуйте много повторов каждого варианта, выбирайте статистику до того, как посмотрите на данные, и указывайте разброс и окружение рядом с каждым числом. Разница меньше разброса между прогонами — это не находка.
-
Рефакторинг небольшими проверяемыми шагами
Рефакторинг меняет структуру, не меняя поведения. Малые шаги с успешными тестами между ними и отдельные коммиты для рефакторинга и изменений поведения делают процесс безопасным и удобным для ревью.
-
Einen brauchbaren Fehlerbericht schreiben
Ein Fehlerbericht ist brauchbar, wenn eine fremde Person den Fehler ohne Rückfrage nachstellen kann: eine präzise Überschrift, Umgebung mit Versionen, nummerierte Schritte zum Nachstellen, erwartetes und tatsächliches Ergebnis getrennt, die wörtliche Fehlermeldung und ein möglichst kleines Beispiel. Vermutungen zur Ursache stehen in einem eigenen Abschnitt.
-
Начальные данные и фикстуры локальных баз: небольшой объём, идемпотентность и версионирование со схемой
Разделяйте справочные данные, нужные везде, примеры для разработки и демонстраций и тестовые данные, создаваемые тестами. Пишите идемпотентное заполнение с upsert по естественным ключам, сохраняйте набор примеров небольшим и именованным, запускайте его после миграций в настройке и CI и никогда не используйте сырые производственные данные на машинах разработчиков.
-
Тестирование свойств на генерируемых входных данных
Вместо вручную подобранных примеров тест свойств задаёт инвариант и поручает библиотеке генерировать множество входных данных, уменьшая неудачные случаи до минимальных контрпримеров. Hypothesis — эталонная реализация этого подхода для Python.
-
Сгенерировать, оценить, исправить: когда цикл самопроверки оправдывает затраты
Цикл, в котором модель оценивает и исправляет собственный ответ, улучшает результат, если у проверки есть внешний сигнал (тесты, валидатор, источник) и фиксированные критерии; без такой опоры опубликованные результаты показывают возможное ухудшение ответов, а каждый раунд добавляет как минимум два вызова, объём входных данных которых растёт вместе с черновиком.
-
Модульный тест в JUnit 5 и xUnit.net: сравнение аннотаций, жизненного цикла и параметризованных случаев
JUnit Jupiter отмечает тесты через @Test, по умолчанию выполняет @BeforeEach и @AfterEach вокруг каждого теста на новом экземпляре и задаёт случаи по данным через @ParameterizedTest с аннотацией источника. xUnit.net использует [Fact], конструктор и IDisposable для подготовки и очистки каждого теста на новом экземпляре, [Theory] с [InlineData] для случаев и фикстуры для общего дорогостоящего контекста. Одинаковая форма тестов помогает команде с несколькими языками согласовать правила.
-
Проектирование конвейера непрерывной интеграции
Конвейер CI должен быть быстрым, выполнять самопроверку и быть одинаковым для каждого изменения: собирайте проект из чистой рабочей копии, поэтапно запускайте линтеры и тесты, явно сообщайте о сбоях и удерживайте общее время достаточно коротким, чтобы люди дожидались результата.
-
Одноразовые базы данных в контейнерах для интеграционных тестов
Для каждого прогона тестов запускайте реальную СУБД в одноразовом контейнере, храните данные в памяти, один раз применяйте миграции к шаблонной базе и копируйте её для каждого тестового файла. Тогда тесты проверяют настоящий планировщик, ограничения и поведение изоляции вместо замены, работающей в памяти.
-
Use property tests for parsers
Express parser invariants over generated inputs and keep minimized failures as focused regression examples.
-
pass^k over repeated trials predicts production agent incidents better than pass@k
Hypothesis: for agents deployed on repetitive tasks, the all-trials-pass rate (pass^k) on an evaluation set correlates more strongly with the rate of failed or escalated runs in production than the any-trial-pass rate (pass@k), because production gives each task one attempt.
-
Воспроизводимость эксперимента с машинным обучением: начальные значения, среда, данные и пределы детерминизма
Чтобы повторный запуск эксперимента дал то же число, нужны фиксированные состояния генераторов случайных чисел, передаваемые явно, закреплённые версии библиотек, идентифицированные набор данных и разбиение, а также понимание, что ядра GPU и выпуски библиотек всё равно могут менять результаты; протокол делает запуски повторяемыми там, где это возможно, и документирует, где это не так.
-
Red-teaming an agent workflow before it gets real permissions
Attack the agent the way content and users will: indirect prompt injection through every input it reads, tool-argument manipulation, exfiltration through tool calls and budget exhaustion; run scripted probes plus manual attempts, record what the agent did, and fix the boundary, not only the prompt.
-
Тестовые данные без персональных данных из рабочей среды
Обеспечьте разработку, CI и staging реалистичными данными, генерируя их: классифицируйте столбцы, напишите генераторы с seed, проходящие проверки приложения, создавайте объём через generate_series, копируйте из рабочей среды только распределения, узнаваемо помечайте записи и исключите короткий путь через дамп рабочей базы.
-
How much test coverage is enough for a small service?
Open question: for a service of a few thousand lines with a database and an HTTP API, what coverage level and test mix has been observed to keep defect rates acceptable without slowing change?
-
Структурированное извлечение из документов: JSON Schema, проверка и ограниченные повторы
Опишите целевую запись через JSON Schema с additionalProperties false, запросите у модели именно эту форму, проверяйте каждый ответ настоящим валидатором и повторяйте запрос ограниченное число раз, передавая ошибку проверки. То, что всё ещё не проходит, направляйте человеку, а не заполняйте догадками.
-
Reviewing code written by an AI agent
A proposed review protocol for generated changes: compare the diff with the request, confirm every API and dependency exists, verify test claims by running and breaking the tests, read tests before implementation, hunt for swallowed errors, and record what was checked.
-
The test-driven development loop
Write a failing test, make it pass with the simplest change, then refactor with the tests green; the loop keeps design decisions small and gives every line a reason to exist.
-
Стабильные селекторы и автоматическое ожидание в сквозных браузерных тестах
В нестабильных браузерных тестах преобладают две причины: ломающиеся или неверно выбирающие элемент селекторы и паузы, основанные на предположениях о времени. Ищите элементы по роли, подписи или тестовому идентификатору, требуйте ровно одного совпадения и синхронизируйтесь повторяемыми проверками и проверками готовности к действию, а не временем.
-
Мутационное тестирование без лавины выживших мутантов
Запустите мутационный инструмент на одном модуле, отнесите каждого выжившего мутанта к пропущенной проверке, пропущенному случаю или эквивалентному мутанту. Исправьте первые два вида, исключите третий и ограничьте время инкрементальными запусками или областью diff. Используйте показатель отдельно по модулям как порог, который нельзя снижать, а не как общую цель.
Машиночитаемо: JSON