В этом уроке я расскажу, зачем нужно тестирование, и на простых примерах покажу, как оно работает. Мы рассмотрим три типа тестов: локальные, инструментальные и UI.

 

 

Зачем нужно тестирование?

Тестирование - это очень важный и необходимый инструмент, который вы можете использовать, чтобы минимизировать количество ошибок в вашем приложении.

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

Чтобы вам каждый раз не проверять все возможные случаи вручную, вы можете написать тесты. После того, как вы внесли очередные изменения в код, вы просто запускаете тесты, и они вам сообщат, если что-то вдруг стало работать не так, как должно.

 

 

 

Как работает тестирование?

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

Если вы тестируете приложение Калькулятор, то вы в тесте укажете, что, при использовании чисел 2 и 3, их сумма должна быть равна 5.

Далее вы запускаете тест. Он возьмет заданные вами входные данные (т.е. числа 2 и 3, операция - сумма), использует их в вашем приложении и убедится, что полученный результат совпадает с тем, что вы указали (5).

Кроме этого сценария (2+3=5), вы в тесте пишете проверки и для остальных операций: вычитание, умножение, деление. Например, обязательно надо протестировать попытку деления на 0. Ваше приложение не должно крэшить при выполнении такого теста.

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

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

 

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

 

 

Типы тестов

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

Два EditText, кнопки со стандартными операциями и TextView с результатом.

Для этого приложения мы создадим три типа тестов: локальный, инструментальный и UI.

 

 

Локальный тест

Этот тест предназначен для тестирования кода, который не зависит от компонентов Android API. Т.е. тестируемый код - это чистый Java код, который ничего не знает про Activity, Fragment, Context и пр., поэтому для запуска не нужен Android-эмулятор или реальное устройство. Локальные тесты запускаются прямо на вашем компьютере, используя Java-машину.

 

В приложении Калькулятор есть класс Calculator, который выполняет вычисления:

public class Calculator {

    public int add(int a, int b) {
        return a + b;
    }

    public int subtract(int a, int b) {
        return a - b;
    }

    public int multiply(int a, int b) {
        return a * b;
    }

    public int divide(int a, int b) {
        if (b != 0) {
            return a / b;
        } else {
            System.out.println("Divide by 0");
            return 0;
        }
    }
}

Для упрощения, используем int в качестве типа чисел.

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

 

Подробный код теста выглядит примерно так:

Calculator calculator = new Calculator();

int actual = calculator.add(1,2);
int expected = 3;
assertEquals(expected, actual);

Сначала создаем экземпляр класса Calculator. На нем будем проводить тест

В переменную actual помещаем результат работы объекта calculator, который сложит два числа: 1 и 2.

В переменную expected пишем ожидаемый результат, который должен получиться при сложении чисел 1 и 2, если calculator работает правильно. 1 + 2 должно быть равно 3.

И методом assertEquals сравниваем ожидаемый результат и то, что вернет нам calculator. Если значения окажутся не равны, то при запуске теста метод assertEquals выбросит ошибку.

Т.е. мы знаем как должен сработать calculator, и мы сверяем это с тем, как он действительно сработал. Результаты должны совпадать. Calculator должен работать так, как мы ожидаем.

 

Переменные actual и expected я использовал только для наглядности. Тот же тест можно записать так:

Calculator calculator = new Calculator();
assertEquals(3, calculator.add(1,2));

 

Класс теста будет выглядеть так:

public class CalculatorTest {

    private Calculator calculator;

    @Before
    public void setUp() throws Exception {
        calculator = new Calculator();
    }

    @Test
    public void addition() throws Exception {
        assertEquals(3, calculator.add(1, 2));
    }
}

Метод addition имеет аннотацию @Test. Это означает, что метод является тестовым и он будет вызван при запуске тестирования. Этот метод тестирует, как работает метод Calculator.add(). Название тестового метода может быть любым, я назвал его addition (сложение), т.к. в нем тестируется операция сложения.

Обратите внимание, я вынес создание объекта сalculator в метод setUp. Этот метод имеет аннотацию @Before, которая означает, что этот метод будет выполнен перед выполнением каждого @Test метода. Это избавляет нас от необходимости самим создавать экземпляр calculator в каждом @Test методе.

Т.е. перед выполнением addition будет выполнен setUp, который создаст экземпляр calculator, и addition использует этот экземпляр.


Запустив этот тест, мы получим сообщение о том, что тест успешно пройден

Т.е. тест выполнил метод add с значениями 1 и 2, получил 3, сравнил это с ожидаемым значением (3) и выяснил, что результат совпал с ожиданием. Значит программа работает так, как мы от нее ожидали.

При запуске теста нам не понадобилось Android устройство. Тест выполнился на компьютере, в Java-машине.


Если сейчас открыть Calculator и поломать там операцию сложения, поменяв плюс на минус

    public int add(int a, int b) {
        return a - b;
    }

то при запуске тест покажет следующее

Тест сообщает, что ожидалось значение 3, а результат получился -1.  Т.е. calculator сработал не так, как мы ожидали, а это означает, что в нем появилась ошибка.

Кроме метода addition, мы можем в тестовом классе создать и другие @Test методы для тестирования остальных операций (вычитание, умножение, деление). А можем создать общий метод, который будет тестировать все операции.

Назовем его operations.

    @Test
    public void operations() throws Exception {
        assertEquals(3, calculator.add(1,2));
        assertEquals(1, calculator.add(1,0));

        assertEquals(1, calculator.subtract(7,6));
        assertEquals(-2, calculator.subtract(0,2));

        assertEquals(12, calculator.multiply(3,4));
        assertEquals(0, calculator.multiply(9,0));

        assertEquals(2, calculator.divide(8,4));
        assertEquals(0, calculator.divide(5,0));
    }

Тестируем все 4 операции разными значениями. А операцию divide тестируем делением на 0. Это случай, который потенциально может привести к непредсказуемому результату или крэшу, поэтому его надо обязательно проверять в тестах.


Результат запуска будет таким

Во всех assert-методах результат совпал с ожиданием. Все ок.

Также в лог вывелось сообщение, что была попытка выполнить деление на 0. Это наше сообщение, мы выводим его в методе Calculator.divide просто для информации.

 


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

    public int divide(int a, int b) {
        if (b == 0) {
            System.out.println("Divide by 0");
        }
        return a / b;
    }

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

 

Запустим тест

Тест поймал ошибку, потому что мы в методе operations тестировали сценарий с делением на 0.

assertEquals(0, calculator.divide(5,0));

Мы предполагали, что деление на 0 может быть опасным и его надо обязательно включить в тесты. И мы не ошиблись. Тест вызвал метод calculator.divide с аргументами 5 и 0, получил крэш и сообщил нам об этом.

 

Если закомментировать строку проверки деления на 0 в методе operations

    @Test
    public void operations() throws Exception {
        assertEquals(3, calculator.add(1,2));
        assertEquals(1, calculator.add(1,0));

        assertEquals(1, calculator.subtract(7,6));
        assertEquals(-2, calculator.subtract(0,2));

        assertEquals(12, calculator.multiply(3,4));
        assertEquals(0, calculator.multiply(9,0));

        assertEquals(2, calculator.divide(8,4));
        //assertEquals(0, calculator.divide(5,0));
    }

и запустить тест, то он вам напишет, что все ок.


Тест прошел успешно, потому что он не проверял деление на 0. А все остальное, что вы просили его проверить, сработало без ошибок.

Это очень важный момент тестирования, который необходимо понять. Тест найдет вам ошибку, только если вы в нем опишите ситуацию, которая может привести к ошибке.

Т.е. понятно, что нет смысла писать тесты типа:

assertEquals(3, calculator.add(1,2));
assertEquals(7, calculator.add(3,4));
assertEquals(11, calculator.add(5,6));
assertEquals(15, calculator.add(7,8));

Тут очевидно, что если сработает первый, то сработают и остальные. Чтобы проверить операцию сложения достаточно одной из этих четырех строк.

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

 

Инструментальный тест

Т.к. мы пишем Android приложения, то чистой Java никак не обойтись. И у вас обязательно будут классы, которые взаимодействуют с классами из Android API.

В этом случае, уже не получится запустить тест локально на Java-машине вашего компьютера. Т.е. локальные тесты нам тут не подходят. Нужен Android эмулятор или реальное устройство. Именно на них будут выполняться инструментальные тесты. А значит, в этих тестах мы можем использовать различные Android классы.

Тут необходимо сделать небольшое отступление и сказать, что есть таки возможность писать локальные тесты, которые смогут протестировать объекты, связанные с Android. Но, во-первых, иногда есть необходимость запустить тест именно на Android, а, во-вторых, нам об этом пока рано говорить. Мы эту тему рассмотрим чуть позже. Пока примем как данность, что тесты для объектов, связанных с Android, необходимо запускать на Android.

 

Для примера снова возьмем Калькулятор. Он хоть и простой, но умеет сохранять данные при закрытии. При выходе из приложения, данные из полей ввода сохраняются в Preferences. А при следующем запуске восстанавливаются обратно.

Для данных используется контейнер Values.

public class Values {

    private String firstOperand = "";
    private String secondOperand = "";

    public boolean equalsToValues(Values values) {
        return firstOperand.equals(values.firstOperand)
                && secondOperand.equals(values.secondOperand);
    }

    // getters and setters

}

Он хранит два значения и имеет метод для сравнения себя с другим Values.


И есть SaveValuesHelper, который умеет сохранять Values в Preferences и потом читать его оттуда же.

public class SaveValuesHelper {

    public static final String KEY_FIRST_OPERAND = "first_operand";
    public static final String KEY_SECOND_OPERAND = "second_operand";

    private final SharedPreferences sharedPreferences;

    public SaveValuesHelper(SharedPreferences sharedPreferences) {
        this.sharedPreferences = sharedPreferences;
    }

    public void saveValues(Values values) {
        sharedPreferences.edit()
                .putString(KEY_FIRST_OPERAND, values.getFirstOperand())
                .putString(KEY_SECOND_OPERAND, values.getSecondOperand())
                .commit();
    }

    public Values readValues() {
        Values values = new Values();
        values.setFirstOperand(sharedPreferences.getString(KEY_FIRST_OPERAND, ""));
        values.setSecondOperand(sharedPreferences.getString(KEY_SECOND_OPERAND, ""));
        return values;
    }
}

 

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

Тест может выглядеть так:

    @Test
    public void saveAndReadValues() throws Exception {
        Context appContext = InstrumentationRegistry.getTargetContext();
        SharedPreferences sharedPreferences = appContext.getSharedPreferences("test", 0);
        sharedPreferences.edit().clear().commit();
        SaveValuesHelper saveValuesHelper = new SaveValuesHelper(sharedPreferences);

        Values saveValues = new Values();
        saveValues.setFirstOperand("5");
        saveValues.setSecondOperand("2");
        saveValuesHelper.saveValues(saveValues);

        Values readValues = saveValuesHelper.readValues();
        assertTrue(saveValues.equalsToValues(readValues));
    }

Мы используем объект InstrumentationRegistry, чтобы получить Context и создаем абсолютно реальный рабочий объект SharedPreferences, в котором очищаем все данные для чистоты эксперимента. Далее создаем SaveValuesHelper и даем ему для работы SharedPreferences.

Для теста создаем новый объект saveValues с значениями 5 и 2 и просим saveValuesHelper сохранить эти значения в префы. Затем просим saveValuesHelper вытащить значения из префов в readValues. И методом assertTrue проверяем, что метод equalsToValues вернет true. Т.е. те данные, которые мы записали (saveValues) должны быть равны тем значениям, которые мы потом считали (readValues).

Если тест пройдет успешно, значит saveValuesHelper корректно сохраняет и считывает значения.

Запускаем тест и видим, что все ок - тест пройден успешно.

Обратите внимание на кучу текстовой информации. Ее не было в локальных тестах.

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

 

Давайте сделаем ошибку в программе, чтобы тест выявил ее.

От заказчика поступило требование, что при выходе из приложения надо сохранять в префы не только операнды, но и результат операции. И при открытии приложения восстанавливать.

Не вопрос. Добавляем поле result в Values.

public class Values {

    private String firstOperand = "";
    private String secondOperand = "";
    private String result = "";

    public boolean equalsToValues(Values values) {
        return firstOperand.equals(values.firstOperand)
                && secondOperand.equals(values.secondOperand)
                && result.equals(values.result);
    }

    // getters and setters

}

 

И добавляем сохранение этого result в методе saveValues:

public class SaveValuesHelper {

    public static final String KEY_FIRST_OPERAND = "first_operand";
    public static final String KEY_SECOND_OPERAND = "second_operand";
    public static final String KEY_RESULT = "result";

    private final SharedPreferences sharedPreferences;

    public SaveValuesHelper(SharedPreferences sharedPreferences) {
        this.sharedPreferences = sharedPreferences;
    }

    public void saveValues(Values values) {
        sharedPreferences.edit()
                .putString(KEY_FIRST_OPERAND, values.getFirstOperand())
                .putString(KEY_SECOND_OPERAND, values.getSecondOperand())
                .putString(KEY_RESULT, values.getResult())
                .commit();
    }

    public Values readValues() {
        Values values = new Values();
        values.setFirstOperand(sharedPreferences.getString(KEY_FIRST_OPERAND, ""));
        values.setSecondOperand(sharedPreferences.getString(KEY_SECOND_OPERAND, ""));
        return values;
    }
}

А вот чтение result в методе readValues добавить мы "забываем".

 

В тесте добавляем тестовое значение 10 для поля Values.result. Остальное не меняется.

    @Test
    public void saveAndReadValues() throws Exception {
        Context appContext = InstrumentationRegistry.getTargetContext();
        SharedPreferences sharedPreferences = appContext.getSharedPreferences("test", 0);
        SaveValuesHelper saveValuesHelper = new SaveValuesHelper(sharedPreferences);

        Values saveValues = new Values();
        saveValues.setFirstOperand("5");
        saveValues.setSecondOperand("2");
        saveValues.setResult("10");

        saveValuesHelper.saveValues(saveValues);

        Values readValues = saveValuesHelper.readValues();

        assertTrue(saveValues.equalsToValues(readValues));
    }

 

Запускаем тест и получаем ошибку

Идем по адресу SaveValuesHelperTest.java:37 и видим там строку:

assertTrue(saveValues.equalsToValues(readValues));

Метод equalsToValues не вернул true, а значит saveValues и readValues не равны, а значит SaveValuesHelper записал одно (5, 2, 10), а считал другое (5, 2). Идем в SaveValuesHelper и обнаруживаем допущенную ранее ошибку.

 

 

 

UI тест

Третий тип теста вполне можно считать реальным живым QA инженером (тестировщиком). UI тест умеет запускать приложение, вводить в поля значения, нажимать кнопки и т.п. А после этого он может проверить в каком состоянии находятся View на экране, что они отображают и т.п.

Давайте рассмотрим пример такого теста.

Приложение Калькулятор при выполнении какой-либо операции (сложение, вычитание и т.д.), читает значения операндов из полей EditText. После этого он проверяет, что операнды не пусты и в случае, когда хотя бы один пустой, выводит сообщение об этом в то же TextView, куда выводится результат.

В коде это выглядит так

        String firstOperandText = editTextFirstOperand.getText().toString();
        String secondOperandText = editTextSecondOperand.getText().toString();

        if (TextUtils.isEmpty(firstOperandText) || TextUtils.isEmpty(secondOperandText)) {
            textViewResult.setText(R.string.empty_operands);
            return;
        }

        // calculator using

 

Создадим тест, который воспроизведет ситуацию с пустым операндом.

    @Test
    public void checkClick() {
        // type 5 value in first EditText
        onView(withId(R.id.first_operand))
                .perform(typeText("5"));

        // press addition button
        onView(withId(R.id.add))
                .perform(click());

        // check that TextView contains error text
        onView(withId(R.id.result))
                .check(matches(withText(R.string.empty_operands)));
    }

В этом тесте мы просим сделать три действия

1) Ввести значение 5 в первый EditText
2) Нажать кнопку сложения
3) Убедиться, что ошибка empty_operands отобразилась в TextView

При запуске тест запустит приложение Калькулятор и выполнит все описанные выше действия. Если вы посмотрите в это время на девайс, вы увидите, как все это происходит. Как будто кто-то запустил приложение и работает с ним.

И тест успешно завершается

 

Давайте и здесь спровоцируем ошибку. Представим, что пришел новый разработчик, не прочитал внимательно тех.задание и решил, что сообщение об ошибке лучше выводить в Toast, а не в TextView.

Вносим изменения в код:

        String firstOperandText = editTextFirstOperand.getText().toString();
        String secondOperandText = editTextSecondOperand.getText().toString();

        if (TextUtils.isEmpty(firstOperandText) || TextUtils.isEmpty(secondOperandText)) {
            Toast.makeText(this, R.string.empty_operands, Toast.LENGTH_SHORT).show();
            return;
        }

        // calculator using

Мы заменили вывод сообщения об ошибке с TextView на Toast.

Запускаем тест и получаем ошибку

android.support.test.espresso.base.DefaultFailureHandler$AssertionFailedWithCauseError: 'with string from resource id: <2131099682>' doesn't match the selected view.
Expected: with string from resource id: <2131099682>[empty_operands] value: Empty operands

Что в переводе означает примерно следующее: не обнаружил в указанном вами TextView строку Empty operands. Тест искал сообщение о пустых операндах в TextView, но не нашел, т.к. оно теперь отображается в Toast. 

В итоге, тестом мы поймали несоответствие программы и тех.задания.

 

 

 

Где хранятся тесты?

Вы наверняка обращали внимание на папки Test и AndroidTest, которые создаются у вас в каждом проекте.

Именно в этих папках и хранятся тесты. В папке Test - локальные тесты, а в папке AndroidTest - инструментальные и UI.

 


Что дальше?

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

От себя могу сказать, что, если вы планируете стать Android разработчиком, то вам имеет смысл изучить эту тему. При устройстве на работу начального/среднего уровня, знание тестирования будет вам очень большим плюсом. А если претендуете на серьезную позицию, то без умения писать тесты никак не обойтись.

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

 

Курс Тестирование

 

Комментарии   

# RE: Урок 1. Зачем нужны тесты и как они работаютЕлена 18.10.2017 12:41
Спасибо за урок!
Читать его понятно, но если попробовать на практике - сложно без люращения к другим источникам. Например, пишите "Запустив этот тест..." но не сказано, как запустить - куда нажать (новичку не понятно - приходится гуглить). В какой папке создавать тесты уже написано в конце урока, а не сразу - при создании класса (
# RE: Урок 1. Зачем нужны тесты и как они работаютDmitry Vinogradov 24.01.2018 13:14
Это вводный урок, который просто рассказывает что такое тесты. А о том, как их создавать и запускать, очень подробно рассказывают следующие уроки.
# Тег br в кодеДаниил 18.04.2018 23:32
В примере кода для saveAndReadValues() на второй строчке есть тег ))

Language

Автор сайта

Дмитрий Виноградов

Подробнее можно посмотреть или почитать.

Никакие другие люди не имеют к этому сайту никакого отношения и просто занимаются плагиатом.

Социальные сети

 

В канале я публикую ссылки на интересные и полезные статьи по Android

В чате можно обсудить вопросы и проблемы, возникающие при разработке



Группа ВКонтакте



Поддержка проекта

Яндекс
410011180491924

WebMoney
R248743991365
Z551306702056

Paypal