Из многих преимуществ разработки через тестирование я считаю, что чувство контроля и всестороннее понимание внутренней работы моих приложений находятся в верхней части списка. TDD делает программирование приятным для меня, потому что я трачу больше времени на прогресс, не боясь вносить изменения или ломать голову над отладкой. Однако бывают ситуации, которые соблазняют меня на «темную сторону» и уводят от процесса «красно-зеленый-рефакторинг». проверит определенный аспект моего приложения. Именно тогда я познакомился с концепцией «тестирования поведения, а не реализации».

Тестирование поведения, а не реализации, означает, что я должен протестировать общедоступный интерфейс приложения и оставить внутренние последствия скрытыми от теста. Преимущество этого в том, что тестирование можно поддерживать. Изменения, скорее всего, произойдут в фактической реализации кода, а не в поведении. Отделив реализацию кода от тестирования, мне не пришлось бы переписывать свой тест, если реализация изменится. Кроме того, тестирование фактического поведения кода служит живой документацией по коду.

Тем не менее, когда я натыкаюсь на то, как я могу протестировать определенный аспект моей программы. Я должен иметь в виду, что я должен тестировать определенное поведение. Если мой код соответствует принципам SOLID, тестирование должно быть возможным. Если это трудно проверить, то, вероятно, это запах кода. Помнить об этом важно, но наличие инструментов, позволяющих это сделать, — вот когда начинает происходить волшебство. Этот пост от дяди Боба освещает различные инструменты, которые я могу использовать для тестирования поведения моего приложения.

  1. Dummies: однако позволяет мне протестировать функцию, для которой требуется параметр; если этот параметр никогда не будет использоваться. Я могу просто передать фиктивный параметр и установить его на что угодно.
  2. Заглушки: это удобно, когда я хочу протестировать функциональность своего приложения, которая может зависеть от другой функции. Если я знаю, что зависимая функция уже работает, я могу переопределить эту функцию, присвоив ей нужное мне значение, и внедрить ее в основную функцию, которую я хочу протестировать.
  3. Шпион: Это позволяет мне проверить, была ли вызвана определенная функция моим приложением.
  4. Истинные моки: я бы использовал настоящие моки, чтобы проверить, какие функции вызывались, с какими аргументами, когда они вызывались и как часто они вызывались. Это способ проверить поведение.
  5. Подделки: я не совсем уверен, что такое подделки, но я понимаю, что это может быть сложно и совершенно другое животное по сравнению с первыми четырьмя, которые были представлены. Я обязательно вернусь к этому, когда буду лучше разбираться в подделках.

Вывод здесь таков: если я упираюсь в стену, не зная, как написать тест для конкретного требования к функции, я должен разбить требование на части, определить ожидаемое поведение и использовать методы тестирования для написания своего теста.