Функциональные и нефункциональные требования к типовым веб-приложениям и методики их достижения,
часто встречающиеся модули приложений,
типовые архитектурные решения,
проблемы горизонтального масштабирования монолитных приложений,
микросервисная архитектура, ее преимущества и недостатки,
еще один шаг в кроличью нору (акторы, шина сообщений, автоматическое управление жизненным циклом модулей, лямбда-архитектура...),
муки выбора.
часто встречающиеся модули приложений,
типовые архитектурные решения,
проблемы горизонтального масштабирования монолитных приложений,
микросервисная архитектура, ее преимущества и недостатки,
еще один шаг в кроличью нору (акторы, шина сообщений, автоматическое управление жизненным циклом модулей, лямбда-архитектура...),
муки выбора.
В целом большинство вещей зависит от человека, который ставит и принимает задачи в проекте. Назовём его "заказчик": в аутсорсе это - реальный заказчик или его представитель, в продуктовом - PM.
Критерии:
1. В проекте чётко описана структура интерфейсов, например, используются JSON-API, REST-API и т.д.
2. В проекте однотипный подход к реализации интерфейсов, т.е. в целом логика работы и порядок одних и тех же end-point для разных сущностей одинаковы или сильно похожи.
3. Заказчик ставит задачу и описывает в ней интерфейс, который хочет увидеть (например, заказчик технарь и сразу прописывает какие HTTP запросы, с какими параметрами и т.д.) Один из самых важных критериев. Могу объяснить, почему.
4. Задачи ставятся в стиле: одна подзадача - один тест. Очень часто встречается такое, что подзадачи - это фактически отдельные тесты (ну или пара тестов на позитивный и негативный сценарий)
5. В языке программирования или технологии есть высокоуровневый тестовый фреймворк с поддержкой интеграционных тестов, либо есть возможность использовать абстрагированный от реализации тестовый фреймворк на другом языке программирования или технологии.
6. В команде нет отдельной команды QA. Один из главных профитов TDD - ментальный. В том, что программист сперва напишет тесты на функционал и несколько раз продумает его перед тем, как начать реализацию. Если тесты будет писать другой человек, то этот профит пропадает.
7. Есть возможность использовать тестовый фреймворк с DSL по типу Cucumber, чтобы тесты заказчику можно было показывать до реализации (называю это утопичным сценарием, в своей практике не достигал, но знаю команды, которые достигали, так что держать в голове это критерий стоит).
Критерии не взаимоисключающие, некоторые даже взаимодополняющие. Необязательно проекту и команде соответствовать всем критериям, чтобы использование TDD стало продуктивным.
А также расскажу, когда TDD использовать не стоит точно!!
Вкратце:
1. Когда в поставленной задаче нет описания структуры интерфейсов (собственно, нет критерия 1 в предыдущем списке)
2. Когда реализуется незаурядная задача
3. Когда бОльшая часть задач в проекте связана с нагрузками или сложными вычислениями, результат которых сложно предсказать.
Критерии:
1. В проекте чётко описана структура интерфейсов, например, используются JSON-API, REST-API и т.д.
2. В проекте однотипный подход к реализации интерфейсов, т.е. в целом логика работы и порядок одних и тех же end-point для разных сущностей одинаковы или сильно похожи.
3. Заказчик ставит задачу и описывает в ней интерфейс, который хочет увидеть (например, заказчик технарь и сразу прописывает какие HTTP запросы, с какими параметрами и т.д.) Один из самых важных критериев. Могу объяснить, почему.
4. Задачи ставятся в стиле: одна подзадача - один тест. Очень часто встречается такое, что подзадачи - это фактически отдельные тесты (ну или пара тестов на позитивный и негативный сценарий)
5. В языке программирования или технологии есть высокоуровневый тестовый фреймворк с поддержкой интеграционных тестов, либо есть возможность использовать абстрагированный от реализации тестовый фреймворк на другом языке программирования или технологии.
6. В команде нет отдельной команды QA. Один из главных профитов TDD - ментальный. В том, что программист сперва напишет тесты на функционал и несколько раз продумает его перед тем, как начать реализацию. Если тесты будет писать другой человек, то этот профит пропадает.
7. Есть возможность использовать тестовый фреймворк с DSL по типу Cucumber, чтобы тесты заказчику можно было показывать до реализации (называю это утопичным сценарием, в своей практике не достигал, но знаю команды, которые достигали, так что держать в голове это критерий стоит).
Критерии не взаимоисключающие, некоторые даже взаимодополняющие. Необязательно проекту и команде соответствовать всем критериям, чтобы использование TDD стало продуктивным.
А также расскажу, когда TDD использовать не стоит точно!!
Вкратце:
1. Когда в поставленной задаче нет описания структуры интерфейсов (собственно, нет критерия 1 в предыдущем списке)
2. Когда реализуется незаурядная задача
3. Когда бОльшая часть задач в проекте связана с нагрузками или сложными вычислениями, результат которых сложно предсказать.