Это спека: а юнит это будет или интеграционник - это как реализовать тест)
но это скорее пример спеки для «высокоуровневого» модуля, где пользователь - юзер. Более «внутренний» модуль может например делать конвертацию загруженной картинки под разные экраны и генерацию тумбы, где пользователь - другой программист. и терминология будет уже более технической. Но принцип тот же: писать спеки в терминах решаемой задачи, а не в терминах внутренней реализации.
Чтобы любой, кто прочитал описания тестов понимал что и зачем модуль делает и мог легко восстановить сломанное поведение или переписать модуль с нуля (например актуально при апгрейде фреймворка или перелопачивании старого говнокода. да и просто экономит время тем, кто будет твой код юзать и поддерживать)
Если использовать методику «сначала тесты», то у вас появится куча тестов, которые будут ломаться в процессе исследования пространства задачи и попыток найти подходящие абстракции.”
Поэтому тесты надо писать в терминах решаемой задачи (aka ее «бизнес-логики»). Тогда можно набросать скелет спецификаций модуля или функции, показать его коллегам или менеджеру для уточнения, обновить, и после этого приступать к реализации
Тоесть не:
- взять айди юзера из базы
- сверить роли с полем access конфига
- вернуть ‘2’ если роль есть в группе rdctrs
- иначе: 0
А:
- если юзер залогинен
- и его роль есть в группе уровня «редакторы» и выше:
- разрешить редактировние
- иначе:
- показать тултип «доступ ограничен»
Тогда и апи тестируемого модуля будет адекватней и понятней, и «валиться в ходе исследования» тесты будут «валидно» - помогая, а не мешая
Не могу сказать, что сам всегда сначала пишу тесты: если задача на «рисеч» чего-то на что в команде нет ни экспертизы ни точных указаний чего мы хотим - то и не понятно чего именно надо тестировать.
Но в большинстве типичных задач, а-ля добавить секцию комментариев к «проектам», или разрешить прикреплять файлы - очень помогает сначала написать и уточнить костяк тестов в виде спецификаций «как это должно быть для юзера»
Это спека: а юнит это будет или интеграционник - это как реализовать тест)
но это скорее пример спеки для «высокоуровневого» модуля, где пользователь - юзер. Более «внутренний» модуль может например делать конвертацию загруженной картинки под разные экраны и генерацию тумбы, где пользователь - другой программист. и терминология будет уже более технической. Но принцип тот же: писать спеки в терминах решаемой задачи, а не в терминах внутренней реализации.
Чтобы любой, кто прочитал описания тестов понимал что и зачем модуль делает и мог легко восстановить сломанное поведение или переписать модуль с нуля (например актуально при апгрейде фреймворка или перелопачивании старого говнокода. да и просто экономит время тем, кто будет твой код юзать и поддерживать)
Поэтому тесты надо писать в терминах решаемой задачи (aka ее «бизнес-логики»). Тогда можно набросать скелет спецификаций модуля или функции, показать его коллегам или менеджеру для уточнения, обновить, и после этого приступать к реализации
Тоесть не:
- взять айди юзера из базы- сверить роли с полем access конфига- вернуть ‘2’ если роль есть в группе rdctrs- иначе: 0А:
- если юзер залогинен- и его роль есть в группе уровня «редакторы» и выше:- разрешить редактировние- иначе:- показать тултип «доступ ограничен»Тогда и апи тестируемого модуля будет адекватней и понятней, и «валиться в ходе исследования» тесты будут «валидно» - помогая, а не мешая
Не могу сказать, что сам всегда сначала пишу тесты: если задача на «рисеч» чего-то на что в команде нет ни экспертизы ни точных указаний чего мы хотим - то и не понятно чего именно надо тестировать.
Но в большинстве типичных задач, а-ля добавить секцию комментариев к «проектам», или разрешить прикреплять файлы - очень помогает сначала написать и уточнить костяк тестов в виде спецификаций «как это должно быть для юзера»
Аффтар, пешы есчо!
Погугли, как выглядит череп бегемота :)
А если учесть, что они жили в британии во времена римской империи - становится понятно, чьи кости вдохновили бритов на придумку легенд