Есть ли какое-то преимущество в написании как классовых, так и мокистских модульных тестов для одного метода?

Question

Можно написать модульные тесты как в стиле классицизма, так и в стиле «мокиста» согласно http://martinfowler.com/articles/mocksArentStubs.html

Повлияет ли написание как классовых, так и mockist модульных тестов для одного метода, надежность кода, поскольку тестируются как состояние, так и поведение?

Мои коллеги, кажется, просто дразнят все время, и, поскольку они являются "примером", предполагается, что я тоже буду дразнить, если у меня нет веских причин не делать этого. (Я новичок в модульном тестировании). Тем не менее, я чувствую, что тестирование только способом mockist предполагает правильность реализации непроверенных приватных методов, и поэтому я хочу также и классические тесты (для косвенного тестирования приватных методов).

Или это пустая трата времени?

Answer 1

Тестирование с помощью Mocks также косвенно тестирует частных методов - любой частный метод должен иметь какой-то открытый метод в стеке вызовов.Если вы достигли 100% покрытия кода вашими открытыми методами, будут вызваны все ваши частные методы.
Как я помню из статьи Фаулера, разница в том, что mockist проверяет внутреннюю работу класса - они проверяют, что ваш классвызывает другие классы API, как они и ожидали.Имеет смысл, когда функциональность вашего класса пострадает, если вы не сможете использовать его корректно - например, если вы не записываете некоторые данные в базу данных или, что еще хуже, пишите неправильные данные.

Answer 2

Приватные методы - это просто внутренняя работа класса.Иными словами, если вы полностью тестируете публичные методы, то частные методы, но по определению должны делать именно то, что им нужно, поскольку важно только публичное поведение.

У меня есть две мысли относительно 'state '.

1) Если состояние внутреннее (частное), то это реализация того, как достигается поведение.Это внутренний «секрет».Если это важно, то протестируйте полученное поведение.

2) Если состояние общедоступное ... нет проблем.

Я бы пошел на насмешку.

Answer 3

Will writing both classist and mockist unit tests for a single method increase robustness of the code since both state and behaviour is tested?

Нет. Двойное тестирование - Дублирование.

В прошлый раз, когда я проверял, подходы не являются исключительными, скорее они дополняют друг друга. Исходя из специфики индивидуального теста, вы можете выбрать лучший подход.

• если вы имеете дело с поведением класса, где зависимости являются дружественными к тестам, используйте основанные на состоянии тесты.
• если вы имеете дело с зависимостью от файловой системы / сети, нет другого выбора, кроме как проверить взаимодействие . Я вызывал SaveFile ()? Однако это не является свободным проходом для введения интерфейсов между любыми двумя классами, которые вызывают друг друга. Хотя это общая критика подхода «mockist», правда состоит в том, что настоящие «mockists» очень усердно работают над обнаружением минимальных надежных ролей / интерфейсов и определением абсолютного минимума (ожиданий). Грузовые культисты определяют интерфейсы между всем, утверждая, что это правильный путь; роли - нестабильные магниты, у тестов слишком много ожиданий, ведущих к хрупким тестам. Каждый раз, когда происходит изменение интерфейса, проводится много тестового обслуживания.

Answer 4

Да. Использование обеих стратегий обеспечит надежность тестируемого кода, поскольку вы тестируете контракт кода между его зависимостями (mockist) и моделируете функциональность производственной среды (state). Смешивая два подхода, вы гарантируете сбалансированный подход к тестированию.

Тем не менее, обратите внимание, что для тестирования на основе состояния обычно требуются дополнительные затраты, поскольку необходимо настроить и настроить среду для всех компонентов, которые относятся к тестируемому объекту. Это обычно приводит к хрупким испытаниям. Достаточно иметь небольшую часть тестов на основе состояния для тестов mockist.

Использование стратегии mockist продвигает Принцип Единой Ответственности, где каждый класс имеет конечный набор обязанностей и зависит от других классов в своих обязанностях. По моему опыту, если обязанности между объектами плохо определены, вы попадете в тестирование на основе состояния, что предполагает проблему инкапсуляции или абстракции.

Answer 5

Как тесты, так и заглушки, как правило, не используются для тестирования закрытых элементов, так как эти элементы являются основой инкапсуляции, и никто не должен полагаться даже на существование закрытых элементов в новых версиях сборки. Если вам нужно провести юнит-тестирование приватных членов, подумайте о том, чтобы прочитать Как вы юнит-тестирование приватных методов? .

Хорошая причина использовать заглушки вместо макетов очевидна, т. Е. Когда вам необходимо проверить состояние объекта после определенного действия, если оно соответствует задаче, вы должны их использовать. Некоторые люди ошибочно полагают, что имитация - это новое поколение модульного тестирования, и нельзя использовать устаревшие заглушки . Там, где на самом деле вы можете эффективно использовать обе техники по отдельности или в комбинации.