Процесс тестирования

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

• Изучить UML диаграмму состояний
• Попробовать написать план тестирования в простом виде
• Попробовать написание автоматизированного тестирования пр ипомощи JUnit

UML State-Machine diagram

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

Составление плана тестирования

В простом случае наиболее важные вопросы для тестирования: что будем тестировать и как будем тестировать?

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

Второй вариант как составить тестовые ситуации -- определить классы эквивалентности и протестировать каждый и них. Класс эквивалентности -- это такое множество входных данных, на который тестируемый функционал применяет одну логику. Классический пример для иллюстрации -- функция сложения входной переменной с константой

int foo (int a) {
   return 42 + a;
}

Поскольку у нас может произойти переполнение результата при a прнадлежащему [Integer.MAX_VALUE - 41; Integer.MAX_VALUE]. Соответсвенно мы имеем 2 класса: a < Integer.MAX_VALUE - 42 и a > Integer.MAX_VALUE - 42, а так же проверить, что в граничном значении Integer.MAX_VALUE - 42 программа работает корректно и выдается ожидаемый Integer.MAX_VALUE. Реализовав тесты мы бы обнаружили, что в случае переполнения вместо генерирования исключительной ситуации мы получили отрицательное число, а значит разработчику этой функции нужно исправить ее реализацию, а в случае реализованного CI с автоматизированным тестированием его код бы не прошел в репозиторий.

Модульное тестирование при помощи JUnit

У данной библиотеки отличная документация, читать предлагаю прямо вот с этого раздела. Читать и реализовывать сразу. Тестируете функционал графа? Создаете в пакете тестирвоания класс GraphTest, делаете поле класса Graph, инициализируете для тестирования в методе с аннотацией @BeforeAll , если надо пересоздавать под каждый тест -- @BeforeEach