iPhone Xcode Есть ли способ протестировать методы без загрузки симулятора? - PullRequest
0 голосов
/ 24 июля 2010

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

например в моем методе main.m:

#import <UIKit/UIKit.h>

int main(int argc, char *argv[]) {
        testMethod();
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    int retVal = UIApplicationMain(argc, argv, nil, nil);
    [pool release];
    return retVal;
}


void testMethod() {
    NSString *body = @"{\"username\":\"name\",\"password\":\"123\"}";
    NSLog(@"body=%@",body);
}

Все, что я хочу сделатьЗапустите этот код и посмотрите, что выводит консоль (имитатор не нужен).Это возможно в xCode?

Ответы [ 2 ]

3 голосов
/ 24 июля 2010

Это идеальная ситуация для модульного тестирования .Для разработки iPhone я использовал GH-Unit .

Будут некоторые накладные расходы по настройке модуля GH и обучению написанию правильных модульных тестов, но выигрыш будет таким:

  1. Вы сможете быстро написатьи проверьте свой метод и убедитесь, что он работает правильно.
  2. Тесты будут существовать вечно, так что вы можете реорганизовать свой метод тестирования и быть уверенным, что вы ничего не нарушаете.

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

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

Еще одно преимущество: самостоятельное документирование.Если вам когда-нибудь понадобится дать пример кода о том, как использовать ваши классы, просто скопируйте и вставьте код из модульного теста.

Я не занимаюсь тест-ориентированной разработкой и не разбираюсь в 100% охвате, но, как вы, вероятно, можете сказать из этого поста, мне нравятся некоторые юнит-тесты.Раньше я прыгал через все виды неуклюжих обручей, настраивая небольшие терминальные проекты, чтобы позволить мне тестировать свои классы без лишних затрат на запуск всего приложения.Через некоторое время я понял, насколько все это глупо, и научился тестировать свои занятия.Это сильно повлияло на мою производительность.


@ jlehr предложил OCUnit, который лучше интегрируется с Xcode и намного проще в настройке.Я бы держался подальше от OCUnit на iPhone, хотя.У меня было много проблем с выполнением моих модульных тестов в отладчике во время симуляции с OCUnit.Если вы можете сначала написать идеальные модульные тесты, возможно, это не проблема :-D GHUnit позволяет отлаживать ваши модульные тесты прямо из коробки.

Хотя это только для iPhone dev.Если вы используете OS X, тогда OCUnit - отличный выбор для ваших модульных тестов.Существует множество других тестовых сред, но GHUnit - единственная, которую я пытался использовать, которая очень хорошо работает с разработками для iPhone.

3 голосов
/ 24 июля 2010

Не совсем, нет. Если вы действительно этого хотите, вы можете создать новый проект XCode в виде «утилиты командной строки» (в шаблонах Mac OS X), которая будет работать быстрее, поскольку не требует загрузки симулятора. Если вы просто выполняете манипуляции с NSString, тот же код будет работать в Mac OS X.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...