Можно ли протестировать метод в классе Activity? - PullRequest
Новая
       9

Можно ли протестировать метод в классе Activity?

0 голосов
/ 31 октября 2018

Всем рекомендовано следовать шаблону MVP или MVVM для поддержания читабельности и тестируемости кода. Теперь у меня есть сомнения. Сейчас я изучаю юнит-тестирование и пишу код формально. Не используя никаких шаблонов. Теперь мой вопрос, могу ли я проверить свой код следующим образом?

Моя основная деятельность: 

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main); 
    }

    public boolean testMethod(int value){
       return value== 5?true:false;
    }
}

Мой тестовый класс: 

@RunWith(MockitoJUnitRunner.class)
public class ExampleUnitTest {
 MainActivity mainActivity = new MainActivity();
@Test
    public void testMethod(){
        boolean result = mainActivity.testMethod(5);
        assertEquals(true,result);
    }
}

Во время выполнения теста я не получил никаких ошибок или проблем. Так это правильный способ тестирования? Или что будет, если я буду следовать этому методу? Я также начинаю переносить свой код в шаблон MVP, но я хочу прояснить свои сомнения. Пожалуйста, дайте мне знать причину, по которой я не должен следовать формальному кодированию для модульного тестирования.

1 Ответ

0 голосов
/ 31 октября 2018

Ваш простой пример работает, потому что тестируемый код фактически не зависит от класса Activity или какого-либо состояния пользовательского интерфейса. Попробуйте написать тест для кода, который на самом деле зависит от состояния пользовательского интерфейса, например 

public boolean verifyInput() {
    EditText edit = findViewById(R.id.edit1);
    return edit.getText().toString().startsWith("0");
}

Если вы продолжите идти по этому пути, вы заметите следующее:

  • Ваш класс Activity будет становиться все больше и больше (анти-паттерн "Бог-объект").
  • Код, который на самом деле зависит от состояния пользовательского интерфейса (ваш пример этого не делает), не может быть написан с помощью простого модульного теста, для которого потребуется тестирование Android. То есть тесты больше не смогут выполняться на вашем хост-компьютере, но должны быть выполнены на устройстве и должны быть настроены и привести Activity в правильное состояние.
  • Контрольно-измерительные приборы обычно медленнее и могут быть нестабильными из-за характера всей тяжелой работы, которая потребуется для обработки действий и состояния пользовательского интерфейса. Вы получите ложные отрицания в ваших тестовых прогонах.
  • Методы тестирования станут более сложными, потому что они должны привести пользовательский интерфейс в правильное состояние для проверки логики.

Теперь есть простое решение для всего этого. Отделите основную логику от логики пользовательского интерфейса. Сделайте код, который обрабатывает пользовательский интерфейс, настолько простым, насколько это возможно, и переместите (сложную) базовую логику в отдельный класс. Внезапно у вас появляется второй класс с методами, которые облегчат вам анализ и написание тестов. Этот второй класс также будет соответствовать действиям, которые сможет выполнить пользователь вашего приложения.

Через некоторое время вы тоже захотите разделить 2-й класс, потому что вы заметите, что некоторое подмножество методов не имеет ничего общего с другим подмножеством методов. Таким образом, вы продолжаете модульность и разработку, чтобы вам, как разработчику, было легче понимать и работать с кодом. Это время, когда такие шаблоны, как MVP, MVVM, ... станут удобными.

Обратите внимание, что я не рекомендую вам сразу же использовать шаблоны типа MVVM. Если вы только начинаете изучать программирование, разработку программного обеспечения или Android, совершенно нормально делать то, что вы делаете. Изучив эти «болевые точки», вы узнаете, что многие из нас уже сталкивались, и в это время вы начнете искать улучшения и почему другие рекомендуют использовать конкретные шаблоны или лучшие практики.

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

...