Как можно протестировать наконечники iPhone с помощью логических тестов?

Контроллеры представления модульного тестирования кажутся очень важной частью разработки iPhone (см. Это Статья). Это, однако, требует инициализации контроллеров из пера, что я обнаружил невозможным при логическом тестировании.

Загрузка ресурсов из пакета (см. Этот вопрос) в логическом тесте работает нормально. Даже загрузка перьев возможна так:

    UntitledViewController* controller = [[UntitledViewController alloc]initWithNibName:nil bundle:[NSBundle bundleForClass:[self class]]];

. Однако он работает только до тех пор, пока перо содержит только UIViews. Другие представления (я пробовал UITableView и UISwitch) приводят к сбою otest с кодом 138.

Можно ли проверить мои перья с помощью логических тестов, и если да, то как?


iphone objective-c unit-testing octest
person Community    schedule 08.07.2010    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Это зависит от того, что вы пытаетесь проверить. Если вы хотите убедиться, что ваши привязки настроены правильно, прочтите статью Криса Хэнсона о модульном тестировании вашего интерфейса Cocoa < / а>. Я лично считаю, что это излишество и приводит к увеличению количества не очень полезного тестового кода. Но это всего лишь мои 2 цента.

Если вы действительно попытаетесь взаимодействовать с этими элементами интерфейса в своем тесте, вы в конечном итоге столкнетесь с множеством ошибок тестирования, как вы обнаружили, особенно с UIActionSheets и UITableViews.

Но ваша цель должна заключаться в модульном тестировании поведения вашего контроллера, а не поведения объектов пользовательского интерфейса Apple. Я обнаружил, что лучше всего использовать OCMock для имитации элементов пользовательского интерфейса и убедитесь, что контроллер выполняет ожидаемые вызовы на них. Вот пара примеров:

  -(void)testClickingAButtonHidesAView {
     //setup
     id mockViewToHide = [OCMockObject mockForClass:[UIView class]];
     [[mockViewToHide expect] setHidden:YES];
     [controller setSomeView:mockViewToHide];

     // hideButtonClicked is an IBAction that is the hide button's target
     [controller hideButtonClicked];
     [mockViewToHide verify];
  }

  -(void)testActionSheetPublishClick {
     // ModelManager is the controller's dependency, which publishes Items
     id mockModelManager = [OCMockObject mockForClass:[ModelManager class]];
     [controller setModelManager:mockModelManager];

     // this doesn't really need to be mocked, but it's a convenient way to create
     // a reference you can validate in expect:
     id mockItem = [OCMockObject mockForClass:[Item class]];
     [controller setCurrentItem:mockItem];

     // when the user clicks "Publish" (the first button on the action sheet), 
     // the controller should publish the current item
     [[mockModelManager expect] publishItem:mockItem];

     // stub object so I know which action sheet was clicked
     id mockPublishActionSheet = [OCMockObject mockForClass:[UIActionSheet class]];
     [controller setPublishConfirmation:mockPublishActionSheet];

     // simulate action sheet click
     [controller actionSheet:mockPublishActionSheet didDismissWithButtonIndex:0];

     [mockModelManager verify];
  }
person Christopher Pickslay    schedule 08.07.2010

arrow_upward
0
arrow_downward

Вместо этого используйте тесты приложений и проверяйте / проверяйте свой пользовательский интерфейс на устройстве.

person Erik    schedule 04.04.2011