Должен ли я сначала писать тесты (после TDD) для слоя представления или выполнять только ручное тестирование и добавлять тесты моментальных снимков после завершения?

Question

Как и ожидалось, у меня обычно возникают трудности при слежении за TDD (т. Е. При написании тестов в первую очередь) со слоем представления.

А именно, для наблюдения или запуска определенных видимых изменений (макета или стиля) мне потребуетсясделать внутреннюю часть представления публичной.Это нарушает инкапсуляцию и позволяет клиентскому коду делать что-то вроде myView.label.text = "User".

Чтобы избежать этого, я либо добавляю методы получения в класс UIView:

var userName: String{ return label.text }

, либо делаю некоторые расширения, которые добавляются только в среду тестирования:

extension MyView{

//avoids making a getter just for the sake of testing, while keeping it private and interchangeable
var userName : String{
   return (viewWithTag(someLabelTage) as! UILabel).text
} 

Другой подход - пропустить рабочий процесс TDD (т. Е. Выполнить тестирование вручную после выполнения функции) и добавить тестирование моментальных снимков (см. https://github.com/pointfreeco/swift-snapshot-testing) в увеличенном покрытии и иметь страховочную сетку при рефакторинге.

Учитывая все это, мне было интересно, есть ли какие-либо другие шаблоны или подходы, которые я могу использовать, чтобы быть более эффективными, сохраняя при этом свою уверенность в коде.

Answer 1

Мне нечего добавить к ответу Спока.Тесты должны быть написаны, чтобы помочь разработке и поддержке кода в будущем.Если они мешают, то либо код неправильно спроектирован, либо это код, для которого ROI является низким.

Шаблон, который стоит упомянуть, - это скромное представление .Есть несколько способов приблизиться к этому, каждый из которых имеет свои компромиссы, но суть состоит в том, чтобы иметь структуры данных, определяющие, как должно выглядеть представление, а затем позволить представлению читать эти структуры данных и устанавливать из них свои свойства.

Это позволяет вам проверить, что структура данных, управляющая представлением, сгенерирована правильно, без необходимости проверять само представление, потому что это просто скромный объект, который читает и устанавливает значения.

Answer 2

Не эксперт в Swift, но независимо от языка / фреймворка, что-то подсказывает мне, что вы действительно усложняете свою задачу.

У меня обычно возникают трудности при следовании за TDD со слоем вида.

Это ожидается.Поддержка View должна быть простой и не иметь никакого поведения (то есть логики домена) вообще.Это должно быть простое взаимодействие с пользователем и привязка данных к элементам управления в представлении.Так что, на мой взгляд, вам не нужен TDD или, если быть точным, юнит-тесты вокруг View.Вы не получите большой пользы от попыток написания модульных тестов для View.

You View может быть более эффективно протестирован с помощью инфраструктуры тестирования UI, такой как Selenium, или вашей собственной инфраструктуры тестирования UI,который проверяет взаимодействие с пользователем.Таким образом, вы в большей степени окупаете инвестиции (ROI), чем пытаетесь использовать TDD для уровня View.