Pull to refresh

Comments 16

Отличный пример.
Было интересно почитать о чем то более менне реальном а не assertTrue(2+2==4)

Спасибо за отличную практическую статью про TDD! Их, как мне кажется, мало — но TDD это как катание на велосипеде — можно долго рассказывать как это, но сложно научиться не попробовав :)


Я бы только хотел добавить одну важную деталь, которой многие люди придерживаются при использовании подхода TDD — это "один тест за раз". Т.е. итерация "red — green — refactor" делается на одном тесте. Это не значит, что по другому никак, но обычно это серьезно помогает фокусироваться и писать действительно минимальный код, чтобы тест прошел. Можно написать и 6 падающих тестов сразу, но это обычно немного рассеивает внимание — что именно мы сейчас реализуем — чтение из очереди или изменение текста кнопки?

С другой стороны, тот же Бек писал про «двигайтесь большими шагами, если уверены в том, что делаете». Наверняка каждому даже очень опытному разработчику приходится сталкиваться с необходимостью реализовать что-то тривиальное — и растягивать этот процесс надолго только ради чистоты техники, имхо, излишне.
К сожалению пример не соответствует действительности и неправильно интерпретирует правила TDD. Согласно TDD не может быть 6 падающих тестов, только один и только первый. После того как первый тест упал, надо править код чтобы он заработал, потом рефакторить, потом писать тест дальше до того момента как он упадет. К слову ошибка компиляции — это тоже упавший тест.

Не знаю-не знаю, смотрю сюда: https://ru.wikipedia.org/wiki/Разработка_через_тестирование
и в разделе "Цикл разработки через тестирование" вижу, что речь идет от тестах во множественном числе (заголовок: "Запуск всех тестов: убедиться, что новые тесты не проходят").


А вот про ошибку компиляции, как упавший тест — очень согласен. Несколько раз видел, как люди пишут тесты используя еще не созданные классы. Такие тесты не то что не выполняются, они просто не компилируются. :)

Похоже просто «трудности перевода» — в английской версии https://en.wikipedia.org/wiki/Test-driven_development написано
Run all tests and see if the new test fails
что в правильном переводе означает
Запустить все тесты и посмотреть что новый тест падает


Всегда читайте оригинал :)

Так дело в том, что и в русском переводе есть и про один новый тест, и про несколько новых тестов. :)

Несколько раз видел, как люди пишут тесты используя еще не созданные классы.

По мне такое похоже на мазохизм ведь IDE сразу укажет на то что класса или метода несуществует, так зачем такое вообще писать, тут ясно и без тестов что не скомпилируется.
Или я не прав и Xcode+Swift не подсвечивает такие ошибки?
Хорошая IDE мало того что укажет, а еще и создаст для вас класс или метод.

Смысл в том что написанный тест определяет задачу которую надо решить (а не решение).

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

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

Очень хорошая статья, спасибо :)
Вот только не стоит вызывать self.presenter.showNextImage(view: self) в методе viewWillAppear. В таком случае, если свернуть и развернуть приложение, покажется следующее изображение.

Нет. Методы жизненного цикла вью-контроллера не вызываются при сворачивании/разворачивании приложения. Можете проверить дебаггером на простом примере.

Поясните, пожалуйста, почему в каждом методе трестируемого presenter-а передается self.view? Почему нельзя передать View при инициализации presenter-а? Есть какие-то ограничения Mock-библиотеки или это стиль написания?

Можно и в самом презентере добавить свойство view (не забыть его сделать weak). Тут кому как удобнее. :)

Sign up to leave a comment.

Articles