Просто поучительный пример.
Вам нужно протестировать класс. Что это значит? Протестировать его поведение, хотя бы основное. Т.е. желательно все методы которые могут использовать. Как у черного ящика. (скрытые не тестируем и можно не тестировать getter&setter).
Как это сделать?
Вы добавили один метод getFurst(). Вероятно, для тестирования. Но первым элементов не должна ограничиваться проверка. Поэтому нужен скорее метод getItem(int); Это приводит к изменению интерфейса вашего класса (замена не нужного метода нужным)
Сделали изменения, протестировали. Ок.
Далее пишете тест на insert. Несколько. И в конце у вас выскакивает исключение. Индекс превышает размер массива. Опа. Вы должны либо явно описать этот случай в документации (генерацию исключения), либо что-то еще сделать. Указать пользователю на этот скользкий случай.
Далее. Есть метод display
Как его протестировать автоматически? Никак. Это наводит на мысль "что-то не так". Не так, скорее потому, что этот метод не должен быть в этом классе. класс занимается сортировкой. Выводом на экран должен заниматься другой класс. Если вдруг понадобиться поменять вывод, то вам придется ковырять класс который уже работает и протестирован. И вы будете лапать снова весь код, с риском дернуть что-то что скрыто поменяет корректную работу.
Дисплей в другой класс.
итак. убрали getFirst. display. добавили getItem.
класс хорошо тестируется. и более удобный интерфейс.
Т.е. вывод из всего: Тестируемость класса зависит от хорошего интерфейса. Требует этого.
Пригодный к тестированию класс практически всегда (чаще всего) это класс который будет легко использовать. Класс который трудно протестировать, чаще всего трудно будет использовать.
Примерно так.
Конкретно по теме.
Просто по коду тестов, вопросов нет. Вопрос про тестирование класса.