Не нарушают ли средства сопоставления ActiveRecord с помощью musta-matchers правило "тестовое поведение, а не реализация"?
Например, если я использую should validate_presence_of в моей спецификации, это только тестирование, что у меня есть validate_presence_of часть кода внутри моей модели, и это тестирование реализации. Что еще более важно, разве эта спецификация не является абсолютно бесполезной для тестирования реальной проблемы, а именно: "Если я не заполню определенное поле, будет ли модель успешно сохранена?"
1 ответ
Некоторые из сопоставителей musta-matchers не проверяют реализацию, они проверяют поведение. Например, посмотрите на источникallow_value (который validate_presence_of использует): #matches? фактически устанавливает значение атрибута экземпляра и проверяет, не вызывает ли это ошибку. Все сопоставители musta-matchers, которые проверяют валидации (его сопоставители ActiveModel), на которые я смотрел, работают одинаково; они фактически проверяют, что модель отвергает плохие значения.
Обратите внимание, что если вы доверяете ActiveModel и ActiveRecord, чтобы они были полностью протестированы, не должно иметь значения, тестируют ли тестеры поведение или просто проверяют, что используются макросы.
Модульное тестирование проверок модели, безусловно, полезно. Предположим, вы выполняете BDD и реализуете простую форму, которая создает экземпляр модели. Сначала вы должны написать приемочный тест (сценарий Cucumber или rspec), который проверяет правильность правильного заполнения формы и успешного создания экземпляра. Затем вы бы написали второй приемочный тест с ошибкой в форме, которая показывает, что при наличии ошибки в форме ни один экземпляр не сохраняется, и форма снова отображается с соответствующим сообщением об ошибке.
Как только вы получите сценарий с ошибочным путем для одной из ошибок, которую можно совершить в форме, вы обнаружите, что если вы напишите больше сценариев с ошибочными путями для других ошибок, они будут очень повторяющимися - единственные вещи это будет отличаться ошибочным значением поля и сообщением об ошибке. И тогда у вас будет много сценариев с полным стеком, выполнение которых займет много времени. Так что не пишите больше, чем первый сценарий ошибки. Вместо этого просто напишите модульные тесты для проверок, которые бы улавливали каждую ошибку. Теперь большинство ваших тестов простые и быстрые. (Это конкретный пример общего метода BDD перехода от приемочных тестов к юнит-тестам для обработки деталей.)
Тем не менее, я не считаю, что сопоставители ActiveRecord должны соответствовать. Учитывая сопоставители, которые проверяют ассоциации, я обнаружил, что мои приемочные тесты всегда вынуждают меня добавлять все ассоциации к моим моделям, которые мне нужны, и в модульных тестах больше ничего не остается делать. Сопоставители ActiveRecord, которые тестируют функции базы данных, которые невидимы для приложения (например, have_db_index) полезны, если вы строго ориентированы на тестирование, но я склонен расслабляться. Кроме того, для чего бы то ни было, сопоставители ActiveRecord не проверяют поведение (которое было бы трудно реализовать), только то, что используются соответствующие макросы.
Единственное исключение, в котором я считаю полезными соответствия в ActiveRecord, должны быть удалены зависимые объекты. Иногда я обнаруживаю, что никакая спецификация принятия уже не вынуждает меня обрабатывать то, что происходит со связанными объектами, когда объект удаляется. ActiveRecord способ сделать это состоит в том, чтобы добавить :dependent вариант к belongs_to, has_many или же has_one ассоциация. Написание примера, который использует musta-matchers ' belong_to или же have_many или же have_one совпадение с .dependent вариант это самый удобный способ, который я знаю, чтобы проверить это.