Как писать простейшие UnitTest'ы к простейшим функциям?

Хочу научиться писать тесты для своих проектов. 

Подскажите какие-нибудь хорошие ресурсы, чтобы научиться тестировать Android приложения.

Насколько важно их использование? 

Сейчас я пишу приложение без их использования и пока не могу оценить их пользу.

Те коды, которые встречаю в интернете, не помню, чтобы где-то в коде встречал тесты. 

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

Допустим есть вот такой метод:

private File getFile(File path) {
    String timeStamp = new SimpleDateFormat("yyyyMMdd_HHmmss").format(new Date());
    return new File(path.getPath() + File.separator + timeStamp + ".html");
}


Как можно к нему написать тест и что нужно для этого сделать?

ПРАВКА

Вот кстати есть ссылка с видео где показан пример теста 

https://www.youtube.com/watch?v=ZJE0MDKJOow
    

Ответы

Ответ 1

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

В вашем конкретном случае, первое что бросается в глаза, это то что метод помече
как private, такой метод нельзя тестировать стандартными методами. Существует мног
теорий насчет того нужно ли тестировать приватные методы или нет. Мое мнение - их можно не тестировать. Правильность работы приватных методов будет проверена неявно когда вы тестируете все открытые методы. Хотя если вы очень хотите то можно пометить метод как 'default' (убрать тип доступa), или можно использовать reflection.

Но допустим ваш метод публичный, тогда анализируя код понимаем, что метод возвращае
новый файл с именем построенным из пути и функции текущей даты. То есть, он делает два действия:
* Создает имя файла
* Создает собственно файл
Тестировать его в текущем виде можно но не интересно. Я бы посоветовал немного поправить ваш код чтобы он был более пригодным для тестирования: 

public File getFileFullName(File path, Date date) {
    String timeStamp = new SimpleDateFormat("yyyyMMdd_HHmmss").format(new Date());
    String fullPath = path.getPath() + File.separator + timeStamp + ".html";
    return fullPath;
}

// где-то в вашем коде
String path = ...
Date now = new Date();
String fileFullName = getFileFullName(path, now);
File file = new File(fileFullName);


// тест для метода getFileFullName в классе ClassUnderTest
@Test
public void testGetFileFullName() {
    String path = "/abc";
    Date date = new Date(1465953124); //2016-06-15 13:12:06

    ClassUnderTest instance = new ClassUnderTest()
    String name = instance.getFileFullName(path, date);

    assertEquals("/abc/20160615_131206.html");
}


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

public class DateTimeUtils {

    private static DateTime fixedTime;

    public static DateTime getCurrentDateTime() {
        if (fixedTime == null) {
            return new DateTime(DateTimeZone.UTC);
        }
        return fixedTime;
    }
    public static void useFixedCurrentTime(DateTime timeToReturn) {
        fixedTime = timeToReturn;
    }
}


Что касается объекта File то здесь вам поможет подмена классов с помощью мокирования. Посмотрите Mockito или PowerMock. 

Еще маленькое дополнение. Если бы вы использовали test-driven development то такой проблемы бы не было.


Ответ 2

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

Придумывание тестов к готовому коду - очень ресурсозатраная задача. Как в плане планирования(ва
нужно вспомнить или выяснить зачем рассматриваемый код вообще был написан), так и 
плане реализации(обычно нужен рефакторинг, много-много рефакторинга). Созданные "постфактум" тесты порой оказываются бесталковыми, написанными просто ради "близкого к 100% покрытия", а на деле не проверяющими то, что действительно стоило бы проверять...

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