xeaf-public/drf-rack
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Добавлены тесты для CoreResponse

Browse Source
This commit is contained in:
Николай В. Анохин
2026-07-20 01:21:20 +03:00
parent b923cac032
commit 2d0911a574
4 changed files with 314 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
testing_2_llm.md
View File

@@ -22,13 +22,14 @@
Правила для файла тестов:
1. Изоляция: Один метод = Один тестовый класс = Один отдельный файл.
2. Именование класса теста: Строго по паттерну `[ИмяТестируемогоКласса][ИмяТестируемогоМетода]Tests`.
- СТРОГОЕ ИСКЛЮЧЕНИЕ: Если тестируется конструктор `__init__()`, то имя метода НЕ должно включаться в название класса. Класс должен называться просто `[ИмяТестируемогоКласса]Tests`. Пример: Для `DemoClass.__init__()` тестовый класс называется `DemoClassTests`.
3. Зеркалирование структуры пакетов: Тесты находятся в пакете `net.xeaf.rack.tests`. Структура подпакетов тестов полностью зеркально повторяет структуру подпакетов исходного кода проекта.
4. Выбор базового класса (Предка):
- Если метод НЕ работает с БД, наследуйся от `CoreSimpleTestCase`.
- Если метод работает с БД, наследуйся от `CoreUserStoryTestCase`.
- Оба класса импортируются из пакета `net.xeaf.rack.core.testing`.
5. Изоляция БД: В тестах с БД используется SQLite в памяти (команда `call_command("rack_test_database")` внутри `CoreUserStoryTestCase.setUp()` автоматически сбрасывает и наполняет БД). База изолирована, данные можно изменять и удалять безболезненно.
6. АВТОМАТИЧЕСКИЙ ПОДБОР И ИСПОЛЬЗОВАНИЕ ВНЕШНИХ МОКОВ: Внутри тестового файла ЗАПРЕЩЕНО объявлять служебные или мок-классы. Так как ты уже генерировал mock-файл для этого класса на Шаге 1, ты должен САМОСТОЯТЕЛЬНО определить, какие из созданных тобой классов `Test...` необходимы для тестирования текущего метода (например, для позитивных сценариев, для тестов на пустоту, на упорядоченность и т.д.). Сформируй имя файла моков как `._[имя_тестируемого_файла_в_snake_case]_mocks` и автоматически пропиши импорт выбранных тобой служебных классов в самом начале файла.
6. АВТОМАТИЧЕСКИЙ ПОДБОР И ИСПОЛЬЗОВАНИЕ ВНЕШНИХ МОКОВ: Внутри тестового файла ЗАПРЕЩЕНО объявлять служебные или мок-классы. Так как ты уже генерировал mock-файл для этого класса на Шаге 1, ты должен САМОСТОЯТЕЛЬНО определить, какие из созданных тобой классов `Test...` необходимы для тестирования текущего метода. Сформируй имя файла моков как `._[имя_тестируемого_файла_в_snake_case]_mocks` и автоматически пропиши импорт выбранных тобой служебных классов в самом начале файла.
### ТРЕБОВАНИЯ К ЯЗЫКУ, ОФОРМЛЕНИЮ И СТИЛЮ КОДА (ДЛЯ ВСЕХ РЕЖИМОВ)
- Все комментарии и docstrings пишутся строго на русском языке.
@@ -39,12 +40,13 @@
Тестовый класс для DemoClass.demo_method()
"""
```
Для конструктора паттерн аналогичен: `Тестовый класс для DemoClass.__init__()`.
- Оформление тестовых методов: Докстринг внутри каждого тестового метода должен быть многострочным, оформленным с пустыми строками до и после текста.
- СТРОГОЕ ПРАВИЛО ИМПОРТОВ: Все импорты (включая автоматический импорт только нужных для этого метода классов `Test...` из локального файла моков) должны располагаться только в самом начале файла. Импорты внутри классов или методов не допускаются.
- СТРОГОЕ ПРАВИЛО ИМПОРТОВ: Все импорты должны располагаться только в самом начале файла. Импорты внутри классов или методов не допускаются.
- Тестирование исключений: При проверке исключений обязательно проверяй не только факт выброса ошибки, но и наличие ключевых слов в тексте сообщения через менеджер контекста `with self.assertRaises(ValueError) as context:`.
- Формат ответа: Возвращай ТОЛЬКО чистый код на Python внутри одного блока разметки ```python. Без вводных фраз и пояснений после кода.
### АЛГОРИТМ ТВОЕЙ РАБОТЫ
Пользователь пришлет тебе команду.
- Если это КОМАНДА 1, сгенерируй полный mock-файл и запомни структуру созданных моков.
- Если это КОМАНДА 2, проанализируй целевой метод, вспомни структуру моков из первого шага, автоматически выбери подходящие классы `Test...`, импортируй их из локального mock-пакета в начале файла и сгенерируй изолированный тестовый класс по методологии AAA.
- Если это КОМАНДА 2, проанализируй целевой метод (с учетом исключения для `__init__`), вспомни структуру моков из первого шага, автоматически выбери подходящие классы `Test...`, импортируй их из локального mock-пакета в начале файла и сгенерируй изолированный тестовый класс по методологии AAA.