Помогу бесплатно: Java и SQL⁠⁠

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

Скажем если у вас есть функция которая рассчитывает площадь квадрата по длине его стороны, то для длины стороны 1 , ожидаемый результат результата вычисления площади - тоже 1, 0 -> 0, 2 -> 4, при отрицательном параметре должна случиться ошибка вычисления - это тоже вариант результата и ее нужно сравнить с ожидаемой ошибкой.

Фреймворки/библиотеки (junit, testng, assertj и т.п.) для тестирования упрощают подстановку разных параметров, проверку совпадения результата с ожидаемым, запуск различных тестов и построение отчетов.

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

Обычно хочется тестировать каждым тестом как можно меньше кода, поэтому если тестируемая функция вызывает другую функцию, то мы этого на самом деле хотели бы избежать, для этого существуют так называемые моки - способ сфальсифицировать какую-то функцию. А иногда хочется проверить какие параметры были переданны в эту внутреннюю функцию - для этого используются "шпионы". Шпионы и моки создаются с помощью специальных библиотек типа PowerMock или Mockito. Но вообще в широком смысле вызов функции это и например рест вызов какого-то сервиса, тогда придется его тоже сфальсифицировать - подменить специальным сервисом который создан всецело для целей тестирования, а не осуществления какой-то работы.

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

Какие тесты вы имеете ввиду? Unit? Api? UI?

Есть принцип Arrange Act Assert или подготовка, действие, проверка. На этом и строятся тесты, подготавливаешь данные, среду или еще что, производишь какие либо действия и сравниваешь фактический и ожидаемый результат.

Плюс что за тестирование? Есть разработка через тестирование, есть ui тесты, есть API тесты, есть когда сценарии по bdd пишут

К тестированию лучше подходить с точки зрения, что любое ПО постоянно меняется. Не всегда в лучшую сторону, но меняется постоянно.

Наличие тестов позволяет значительно ускорить внесение изменений. Допустим у Вас есть программа из 10 классов. В один из них Вы добавили новую функциональность. Но классы же связаны между собой. И чтобы убедиться в правильность работы желательно всё протестировать, или ошибка всплывёт при работе приложения.

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

Вот тут мы приходим к тому, что нужно этот процесс автоматизировать.

Суть простая - на каждый метод каждого класса создаётся тест - то есть вызывается этот метод и мы знаем, что должны получить.

Желательно запускать с неправильными данными: передавать отрицательные числа, нули или очень большие значения и смотреть, что произойдёт.