Я регулярно сталкиваюсь с этой проблемой, и я не уверен, как преодолеть это препятствие. Я действительно хочу начать обучение и применять Test-Driven-Development (или BDD, или что-то еще), но похоже, что каждое приложение, которое я делаю, где я хочу применить, это в значительной степени только стандартная база данных CRUD, и я не уверен, как чтобы применить его. Объекты в значительной степени не делают ничего, кроме того, что они сохраняются в базе данных; нет сложной логики, которая должна быть проверена. Существует шлюз, который мне в конечном итоге нужно будет протестировать для сторонней службы, но я хочу сначала создать ядро приложения.
Всякий раз, когда я пытаюсь писать тесты, я заканчиваю тестирование базовых материалов, которые, вероятно, я не должен тестировать в первую очередь (например, getters/seters), но это не похоже на то, что у объектов есть что-то еще. Наверное, я мог бы проверить настойчивость, но мне это никогда не кажется правильным, потому что вы не должны на самом деле нажимать на базу данных, но если вы издеваетесь над этим, вы действительно ничего не тестируете, потому что вы контролируете данные, которые плюют назад; например, я видел множество примеров, где есть макет репозитория, который имитирует базу данных путем циклирования и создания списка известных значений, а тест проверяет, что "репозиторий" может отбросить определенное значение... Я не видя точки такого теста, потому что, конечно, "репозиторий" собирается вернуть это значение; он жестко закодирован в классе! Ну, я вижу это с чистой точки зрения TDD (т.е. Вам нужно иметь тест, говорящий, что вашему репозиторию нужен метод GetCustomerByName или что-то еще, прежде чем вы сможете написать сам метод), но это похоже на следующую догму без каких-либо причин, кроме ее "путь" - тест, кажется, ничего полезного не делает, кроме оправдания метода.
Я думаю об этом неправильно?
Например, выполните запуск приложения управления контактами мельницы. У нас есть контакты и можно сказать, что мы можем отправлять сообщения контактам. Следовательно, мы имеем два объекта: Contact и Message, каждый из которых имеет общие свойства (например, имя, фамилия, адрес электронной почты для контакта и темы и тела и дата для сообщения). Если ни один из этих объектов не имеет какого-либо реального поведения или не должен выполнять какую-либо логику, тогда как вы применяете TDD при разработке приложения, подобного этому? Единственная цель приложения - в основном вытащить список контактов и отобразить их на странице, отобразить форму для отправки сообщения и т.п. Я не вижу здесь каких-либо полезных тестов - я мог бы подумать о некоторых тестах, но они были бы скорее испытаниями для того, чтобы сказать "Смотрите, у меня есть тесты!" вместо того, чтобы фактически тестировать какую-то логику (хотя Ruby on Rails хорошо ее использует, я не считаю, что проверка проверки является "полезным" тестом, потому что это должно быть что-то, о чем заботится рамка для вас)
