Идеальный тест должен быть понятным и легко читаемым. Кроме того, любой тест так или иначе состоит из трёх частей: подготовка данных, действие над системой и проверка — Arrange, Act и Assert. Посмотрите на любой свой тест — и вы так или иначе обнаружите там эти части.

Я однажды разработал тестовый фреймворк для веб-компонентов, который состоял из 3х частей:

1. Описание состояния компонента в начале и подготовка стабов ответов сервера.
2. Одно действие (например, нажатие на кнопку).
3. Описание состояния компонента после акта ИЛИ проверки вызовов моков на команды серверу.

Этого было достаточно, чтобы юнит-тестировать веб-компоненты. Получались супер-декларативные тесты, которые было легко читать и легко писать. К сожалению, сам код фреймворка был утерян где-то в недрах Дойче Банка.

За фреймворком стояли две простые идеи, которые описывают хорошие юнит-тесты:

1. Единственное действие
2. Единственная проверка

Если с единственным действием всё более менее понятно, то насчёт единственной проверки могут возникнуть вопросы: “а что если мне прям очень надо сделать 2 ассерта?”. Смысл правила “единственной проверки” в проверке одной концепции. Если для проверки некой одной идеи требуется 2 ассерта — это допустимо, но важно не нарушать именно этот принцип одной концепции.

Кроме того, структура тестов AAA даёт нам ещё один интересный способ написания тестов. Если вы не знаете, с чего начать, начните с конца: сначала напишите assert, затем act, а затем уже подготовьте систему к этим действиям и проверкам. Таким образом вы сосредотачиваетесь на том, что реально важно в тесте — проверке. А всё остальное приводите уже в соответствие с этой частью.

Тесты должны быть понятными и читаемыми. Структура AAA помогает сделать их таковыми. В идеале, чтобы каждая A занимала одну строку. Вот и получится трёх-строчный тест.

P. S. LLM тоже любят читаемый код больше, чем нечитаемый. Думайте.