Давно покрываю код тестами. По TDD удобно фиксить баги и писать простые модули. Но делать что-то более сложное — мне не понятно как. Пока вопросов у меня больше, чем ответов.
Легко покрыть тестом hello world из тьюториала. Но в реальном мире задачи сложнее в 90% случаев. Исходя из логики тдд, я должен до написания кода написать тесты и моки. Но как мокать то, чего ещё нет? Статьи говорят "продумать архитектуру". Но архитектура — это общий принцип, а не конкретные "потроха". А моки требуют конкретики. Я не знаю заранее, какими средствами я буду реализовывать нужный метод. Я не знаю, какие методы и библиотеки я применю для реализации и как они будут вызываться. Если я буду при проектировании об этом думать, это уже не TDD на мой взгляд, потому что продумать в деталях код и написать его — немного разницы.
Если писать моки на все "потроха" это мешает одному из основополагающих принципов тестов — тестировать внешнее поведение, а не реализацию. И приводит к необходимости модифицировать кучу моков, например, при рефакторинге. Или оптимизации, не меняющей внешнее поведение метода.
Unit-тесты предполагают, что под mock попадает все — БД, вызовы других методов и т.д. Но любая "высокоуровневая" функция на 99% состоит из вызова других функций. Особенно при использовании библиотек и фреймворков. Если все их подменить, в чем смысл теста? Проверить порядок их вызова? Но порядок ещё не гарантирует корректного результата.
Давно покрываю код тестами. По TDD удобно фиксить баги и писать простые модули. Но делать что-то более сложное — мне не понятно как. Пока вопросов у меня больше, чем ответов.