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