@Vorona

Всем привет!

Возник вопрос по поводу тестирования view controller'ов.
Посмотрел, как это делает Jon Reid в своем туториале: http://qualitycoding.org/uiviewcontroller-tdd/
Почитал, как это советует Graham Lee, в своей книге: http://www.amazon.com/Test-Dri... 0321774183

Пишу простенькое наглядное приложение. В основе лежит паттерн MVVM.
Во ViewModel я работаю со слоем BLL, который работает с DAL, готовлю все данные, провожу валидацию данных и т.д.
Во View (ViewController) я уже рендерю эти данные и вывожу на экран.

Сейчас моя задача вывести просто список сущностей в UITableView. т.е. по-сути мне нужно протестить, что в таблице будет создано столько же рядов, сколько имеется сущностей в списке, нужное кол-во секций и т.д.

В вышеупомянутых ресурсах, корректную работу UIVIewController'a тестируют путем вынесения необходимых контролов в публичный интерфейс. Мне это, естественно, не нравится, потому на помощь приходит DependecyInjection при помощи конструкторов. Т.е. при создании вьюконтроллера в тесте, я ему в конструктор передам таблицу, датасорс и делегат и дальше буду проверять их состояние, или же при помощи моков – поведение.

Вопрос: получается, чтобы протестировать разные "куски" функциональности, мне нужно будет создавать новый конструктор для каждой ситуации?
Или же вынести все необходимые компоненты в так называемый Protected хедер и уже при помощи него тестировать?

может какие-то техники знаете?

Добавлено через 7 минут
p.s. скопипастил вопрос в ветке форума о Разработке и тестировании, так как тема касается и этой и той ветки форума.

0

@mobidevelop

Что-то мне сдается, что вы тут гвоздь шуруповертом закручиваете. Тут же чистый Logic Unit Test. Достаточно погонять датасорс. А для этого UI со всему его сложностями не нужен.

Добавлено через 1 минуту
ну или я чего-то не понял

0

@Vorona

ну вот, не logic test это, нужно проверить что viewcontroller правильно соберет модель предоставленную ему viewmodel'ом, ну там по нажатию на кнопку вызовет нужный метод, построит нужное кол-во ячеек в таблице, отобразит правильное значение на лейбе, нас не UI интересует, а то, как он будет строиться, так как это тоже немаловажная деталь приложения, одного тестирования viewmodel тут недостаточно.
ну да, тут датасорс погонять с таблицей, там значение лейбы проверить, аналогично как в примере показано, нажимаем на кнопки и инкрементируем или декрементриуем значение и отображаем его на лейбе, проверить к примеру динамическую синхронизацию с viewmodel

блин увлекся, сорри

вобщем посмотрел еще статейку http://qualitycoding.org/testability-vs-hiding/
советуют выносить в публичный интерфейс и когда группа похожих наберется, рефакторить выделением класса

На самом деле супер удобный этот MVVM подход, я о нем еще на WPF .NET узнал года два-три назад, а тут он на iOS в связке с FRP и очень хорошо себя оправдывает и отлично тестируется, идеально подходит для реюзинга кода и программировании приложений с различными UI, короче всем советую и все дела

0

@mobidevelop

Ну так это тоже выносится в отдельные классы и все радуются. Парсер, валидатор etc. И все это хозяйство оборачивается тестами. А отображалка тупая насколько возможно. Не прокатит?

0

@Vorona

ну это само собой, но все-равно же это все собирается в одном месте - контроллере (в MVC) и получается такая каша, где половина – работа с UI и оутлетами и половина это набор разных утилит и их жесткая привязка ко всем ui контролам и их колбекам, потому отображалка уже и не такая тупая и не такая она отображалка

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

ну и почему mvvm удобнее mvc, так это потому что каждая viewmodel разработана специально для какого-то представления или лучше сказать задачи (но ничего о нем не знает, только у view есть ссылка на viewmodel), где в публичный интерфейс вынесены только те методы, которые нужны только такого рода представлению, а потом само представление может быть разработано как угодно, будь то таблица, грид вью или выпадающий список или вообще мак ось, согласитесь что в случае с mvc это было бы куда геморнее и постоянно пришлось бы чет выдумывать, лепить какие-то if-else и т.д.

снова написал больше чем надо, ладно буду сдержанней

0

@zulkis

Vorona, FRP == "Functional Reactive Programming", реализованное в ReactiveCocoa?
Не пробовал... Только читал что есть такое, удобно говорите?

0

@mobidevelop

Юнит-тесты, как и все в этом мире, хороши в меру. Я не сторонник покрывать ими UI потому, что любой редизайн вызовет необходимость обновления и юнит-тестов (а их обычно получается куда больше, чем собственно кода, да и читать сложнее). Логика все же меняется реже. А мордочку пусть тестеры проверяют.
ИМХО, разумеется.
Но, похоже, мы ушли в сторону от вопроса.

1

@Vorona

вот я сам только пробую, вроде затею FRP прочувствовал с ReactiveCocoa чуть поиграл, но так, чтобы на практике, да еще и одновременно с ООП – еще не очень
а вот в плане баиндингов, замены делегатам, обсерверам – вполне удобно, но чую, что за ним больше потенциала, конечно

хочу с хаскел, лисп и кложур немного поиграться на досуге, чтобы понять лучше функциональное да и реактивное программирование

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

вопрос более менее закрыт тем же человеком, который и начал всю затею тестирования вьюконтроллеров, в этом посте – http://qualitycoding.org/testability-vs-hiding/

да и буду следовать вашим советам по поводу поменьше усердствовать с тестированием UI, спасибо

0