MaxLich

Если из Андроид-приложения:
1) Лишняя работа (каждый же пользователь будет на Андроиде это делать).
2) Лишние затраты аккумулятора, серьезные ограничения на фоновую работу

Поэтому - через сервер (не через веб-сайт).
Плюс данные с сервера можно отдавать в уже переваренном подготовленным к отображению виде и упакованными.

И по уму - серверов должно быть несколько, так как если вы с одного IP адреса начнете обходить все подряд на сайте, то админы сайтов за нагрузку вас и забанить могут

1) Такой вопрос на тостере раз в пару недель, тру программист должен уметь гуглить
2)

в планах познакомиться в дальнейшем с angular, node, react, python

звучит как "в планах научиться водить машину, готовить плов, выстраивать архитектуру БД и завести собаку". Определитесь, что вы хотите? Бэкенд или Фронтенд? Или, хотя бы, с чего вы хотите начать?
3) Вам же в курсе дают php и js, пускай и базово. Углубляйтесь в них. Это не на один месяц/год задачка.
4)

какие инструменты для каких языков лучше использовать

- так сначала языки выучить надо)) Их же просто тонна. Про какие инструменты вообще речь? Инструменты, как и языки, подбираются под конкретную цель

Вы сначала определитесь, с чем именно хотите работать (бэк/фронт/верстальщик/...), от этого выбирайте язык и инструменты.

Конкретно для вашего нынешнего стэка, ИМХО, следующий этап - сборщики (Gulp, Webpack) + babel + разного рода минификаторы, автопрефиксеры, ...

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

Если на русском:
Java. Библиотека профессионала
Java SE 8 (2 тома.)
Год издания: 2016-2017
Автор: Хорстманн К.
Издательство: Вильямс, Диалектика
ISBN: 978-5-8459-2084-3

Java 9. Полный обзор нововведений
Год издания: 2017
Автор: Шаран Кишори
Переводчик: Слинкин А. А.
Издательство: ДМК Пресс
ISBN: 978-5-97060-575-2

Английский
Effective Java (3rd)
Год издания: 2018
Автор: Joshua Bloch
Издательство: Pearson Education Inc.
ISBN: 978-0-13-468599-1, 0-13-468599-7
Java Quick Syntax Reference, 2nd Edition
Год издания: 2018
Автор: Olsson M.
Издательство: Apress
ISBN: 978-1-4842-3440-2
Java 9 Concurrency Cookbook, 2nd Edition
Год издания: 2017
Автор: Gonzalez J.F.
Издательство: Packt Publishing
ISBN: 978178712441
Modern Java Recipes
Год издания: 2017
Автор: Kousen K.
Издательство: O'Reilly Media
ISBN: 978-1491973172
Beginning Java 9 Fundamentals, Second Edition
Год издания: 2017
Автор: Sharan K.
Издательство: Apress
ISBN: 978-1484228432

Самые примитивные интерпретаторы, например bash, считывают файл скрипта с диска построчно и одновременно выполняют каждую считанную строку. Обычные интерпретаторы читают файл, анализируют код, строят AST и уже его выполняют. Современные продвинутые интерпретаторы (такие как PHP, CPython и Javascript V8) после построения AST компилируют его в байткод и выполняют уже байткод. Чаще всего у интерпретируемых языков этот байткод остаётся только в памяти и не сохраняется на диск. В отличии от них, в Java и C# этапы анализа кода и компиляции его в байткод отделены от этапа выполнения байткода. Скомпилированный код сохраняется в файлах и после выполняется виртуальной машиной. Компилируемые языки (C, C++ и прочие) компилируют AST не в байткод, а сразу в машинные инструкции. Впрочем, и они в последнее время всё чаще используют LLVM.

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

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

мусье документацию на жэ-юнит четыре читали?

https://junit.org/junit4/faq.html#atests_7

@Test(expected = MyMegaException.class)
public void testIfItBroke() {
    MyClass mega;
    mega.methodThatThrows(wrong params);
}

и, да, я бы использовал что-то более специфичное, чем Throwable.