Что тут тестировать и зачем? в случае неудачи получим исключение. Названия колонок мы знаем. Данные в контроллере валидируются.
вы должны проверять корректность работы системы. Всего-то. Причем с оглядкой не только на "сейчас" (тут мы и руками можем проверить быстро) но еще с оглядкой на будущее. Если вы планируете этот код выкинуть - тестировать его нет смысла. Вы на автоматизацию тестирования убьете больше времени чем проверите руками.
С другой стороны, если это лишь вершина айсберга, то имеет смысл написать простенький автотестик, который проверяет корректность работы. Так, если мы будем вносить какие-то изменения, например будем добавлять комменты, мы будем уверены на 90% что ничего не сломали. Почему не на 100%? потому что невозможно покрыть все тестовые сценарии да и это не выгодно. Проверяем мы обычно самые вероятные сценарии.
Далее уже все зависит от сложности тестирования. По хорошему наши тесты должны быть маленькие и, главное, ничего не знать о деталях реализации. Скажем вы хотите проверить что система корректно добавляет новости. Самый простой способ это проверить - создать новость и проверить что не вернулись ошибки. Для этого можно составить HTTP запрос и получить HTTP ответ. Максимально просто.
Но такой тест отрабатывает относительно долго. Представьте себе что вы пишите что-то посложнее. И у вас уже 100 различных тестовых сценариев для одого кусочка системы. В итоге этот маленький кусочек будет тестироваться больше минуты, и мы успеем заскучать. Для того что бы упростить - мы дробим этот кусочек еще и еще пока не находятся такие куски, которые мы можем проверить удобно и быстро. Например если вопрос в корректности валидации данных - мы можем тестировать только контроллер, а если вопрос в каких-то бизнес правилах отдельных - мы можем и их отдельно вынести и тестировать. Это будут интеграционные тесты.
В конечном счете мы можем раздробить все до уровня отдельных маленьких модулей, по сути классов, и тестировать их отдельно. Это будет юнит тесты.
Ну и опять же, дробление вниз должно происходить с целью упрощения тестирования и разработки, а не просто так. Потому например никто не покрывает юнит тестами вещи, которые работают например с базой данных. Слишком дорого в поддержке. С точки зрения тестов все должно быть по большому счету похоже на черный ящик. Вы что-то хотите от ящика и проверяете делает ли он это. Как только тесты становятся завязаны на реализацию - тесты начинают приносить боль.
По сути это самое сложное в тестировании. Писать тестируемый и поддерживаемый код, а так же останавливать себя от тестирования "лишних" частей системы или слишком углубляться в тестирование там где этого не нужно.
