Тестирование состояния/Взаимодействия и беспорядок при смешивании (или злоупотребление) их
== проверки оператора, чтобы видеть, являются ли две строки точно тем же объектом.
.equals() метод проверит, имеют ли две строки то же значение.
2 ответа
Я думаю, что Рой Ошеров недавно сказал, что, как показывает опыт, ваши тесты должны быть на 95 процентов основаны на состоянии и на 5 процентов основаны на взаимодействии. Я согласен.
Важнее всего то, что ваш API делает то, что вы хотите, и , что - это то, что вам нужно протестировать. Если вы протестируете механику того, как он достигает того, что ему нужно делать, вы, скорее всего, получите сверхуказанные тесты, которые укусят вас, когда дело доходит до ремонтопригодности.
В большинстве случаев вы можете разработать свой API так, чтобы Тестирование на основе состояний - естественный выбор, потому что это намного проще.
Чтобы изучить ваш пример загрузки: имеет ли значение, что были вызваны GetPackage и GetAllCertificates? Это действительно ожидаемый результат метода загрузки?
Думаю, нет. Я предполагаю, что цель метода загрузки - это Самая причина существования - это заполнение и обслуживание правильного представления.
Таким образом, тестирование на основе состояний будет проверять возвращаемый ViewResult и его ViewModel и проверять, что он имеет все правильные значения.
Конечно, в соответствии с кодом прямо сейчас вам нужно будет предоставить тестовые двойники для packageRepository и certificateRepository, потому что в противном случае будут выброшены исключения, но не похоже, что сам по себе важен вызов методов репозитория.
Если вы используете вместо этого заглушки моков для ваших репозиториев, ваши тесты больше не привязаны к внутренним деталям реализации. Если позже вы решите изменить реализацию метода Upload для использования кэшированных экземпляров пакетов (или чего-то еще), заглушка не будет вызываться, но это нормально, потому что это '
Возникает вопрос: «Если этот код сработал, как я могу узнать?» Это может означать тестирование некоторых взаимодействий или некоторого состояния, это зависит от того, что важно.
В вашем первом тесте Deny изменяет мир за пределами целевого класса. Это требует сотрудничества со стороны службы, поэтому тестирование взаимодействия имеет смысл. Во втором тесте вы делаете запросы к соседям (ничего не меняя за пределами целевого класса), поэтому их заглушка имеет больше смысла.
Вот почему у нас есть эвристика «Заглушки запросов, фиктивные действия» в http://www.mockobjects.com/book