**Пограничные случаи (edge cases)** — это ситуации, которые возникают на экстремальных границах рабочих параметров системы. Если говорить проще: это условия, при которых твой код может «сломаться», потому что они не являются стандартными или ожидаемыми.

Представь, что ты строишь мост. Стандартный случай — по нему едут машины. **Edge case** — по нему одновременно решили пройти 10 000 человек в ногу (резонанс) или ударил редкий для этой местности ураган.

---

### Примеры из мира IT

Чтобы понять суть, давай возьмем простую функцию: **Поле ввода возраста пользователя.**

1. **Happy Path (стандартный путь):** Юзер вводит «25». Всё отлично.
2. **Edge Cases (пограничные случаи):**
* **Отрицательное число:** Юзер ввел «-5». Сломается ли логика?
* **Слишком большое число:** Юзер ввел «150» или «10 000». Как отреагирует база данных?
* **Дробное число:** Юзер ввел «25.5». Округлит ли система это значение или выдаст ошибку?
* **Пустое поле:** Юзер просто нажал «Далее», не введя ничего.
* **Нечисловые данные:** Юзер ввел «Двадцать пять» буквами или эмодзи.



---

### Почему ИИ (Claude, ChatPRD) здесь незаменим?

Человеческий мозг склонен думать о том, как всё *должно* работать (Happy Path). Мы часто забываем о странных и редких ситуациях. ИИ же не устает и обладает огромной базой данных о том, где обычно «падают» приложения.

**Что делает ИИ для автоматизации этого:**

* **Генерация негативных сценариев:** Ты даешь ему описание функции, а он выплевывает список из 20 способов её сломать.
* **Проверка типов данных:** Он напомнит тебе проверить, что будет, если вместо текста придет `null` или гигантская строка на 50 000 символов.
* **Специфические условия:** Он может подсказать случаи, связанные с часовыми поясами (например, переход на летнее время) или медленным 2G-интернетом.

---

### Edge Case vs. Corner Case

В профессиональной среде иногда разделяют эти понятия:

* **Edge Case:** Проблема с одним параметром на пределе (например, очень длинное имя пользователя).
* **Corner Case:** Когда одновременно совпали несколько пограничных условий (например, очень длинное имя пользователя вводится с телефона с разбитым экраном в момент, когда у сервера закончилась память). Такие ошибки ловить сложнее всего.

---

### Как это связано с Unit-тестами?

Когда мы говорили про юнит-тесты в самом начале, я упоминал, что они должны быть **тщательными (Thorough)**. Это как раз про покрытие пограничных случаев.

Хороший разработчик пишет:

1. Тест на правильные данные.
2. 5–10 тестов на «границы» (ноль, максимум, минимум, не тот формат).

### Пример из жизни соло-разработчика:

Если ты используешь управление намерениями, ты можешь сказать Claude:

> «Вот описание моего **User Flow** для регистрации. Сгенерируй список всех возможных **edge cases**, которые могут возникнуть на этапе валидации пароля».

И он выдаст тебе то, о чем ты бы даже не подумал (например, использование символов правой-левой печати или пробелов в начале пароля).

Хочешь, возьмем какую-нибудь функцию твоего будущего проекта и попробуем вместе сгенерировать для неё список самых коварных «пограничных случаев»? Какой функционал разберем?