Проверить метод, который был подвергнут рефакторингу (разделить на несколько методов)?

Как я слышал ранее и недавно узнал в очень хорошем фильме Джона Рейда, некоторые init методы или в приложениях iOS, viewDidLoad методы имеют тенденцию становиться все больше и больше. Я попытался рефакторинг этого метода:

- (void)viewDidLoad {
    // 10+ lines of setting default property

    // 20+ lines of setting up the navigation bar

    // 20+ lines of resetting the view hierarchy
}

Это было заменено очень хорошим и коротким методом, который содержит вызовы других методов с говорящими именами:

- (void)viewDidLoad {
    [super viewDidLoad];

    [self setDefaultResourceNames];
    [self setupRightBarButtonItems];
    [self restoreNavigationControllerHierarchy];

    [[NSNotificationCenter defaultCenter] addObserver: (...)];

}

Теперь эти три метода сейчас проходят модульное тестирование, что намного лучше, чем раньше. Теперь мой вопрос, должен ли viewDidLoad метод также будет проверен?

Для этого я частично смоделировал тестируемый класс и написал следующий тест:

- (void)testViewDidLoadShouldInstantiateControllerCorrectly {
    NewsItemDetailsViewController *sut = [[NewsItemDetailsViewController alloc] init];
    id mockSut = [OCMockObject partialMockForObject:sut];
    [[mockSut expect] setDefaultResourceNames];
    [[mockSut expect] setupRightBarButtonItems];
    [[mockSut expect] restoreNavigationControllerHierarchy];

    [mockSut viewDidLoad];

    [mockSut verify];
}

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

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

Источник

2 ответа

Решение

Это совершенно разумный подход. Вы хотите протестировать два типа вещей: 1) вещи, которые вы не хотите ломать, и 2) вещи, которые вы хотите задокументировать. Если этот подход соответствует одному или обоим критериям, это нормально.

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

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

Источник

Это зависит от того, что вы тестируете. Здесь нет общего решения; вам нужно принять решение на основе вашего собственного профессионального суждения.

Полезно ли в этом случае проверять поток управления или предоставлять для него регрессионную страховочную сеть? Преимущества перевешивают стоимость?

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

Источник
Другие вопросы по тегам