модульное тестирование унаследованного кода: пределы «извлечения и переопределения» против JustMock / TypeMock / moles? - PullRequest
Новая
       32

модульное тестирование унаследованного кода: пределы «извлечения и переопределения» против JustMock / TypeMock / moles?

3 голосов
/ 17 августа 2011

При следующих условиях:

  • очень старая, большая, унаследованная база кода C # без каких-либо тестовых покрытий
  • (почти) каждый класс наследуется от некоторого интерфейса
  • ничего не запечатано

Каковы практические преимущества использования решений на основе API-профилировщика, таких как JustMock и TypeMock, по сравнению с использованием extract & override +, например, RhinoMocks?Есть ли случаи, о которых я не знаю, кроме обхода private / protected, когда использование TypeMock / JustMock и т. Д. Действительно необходимо ?Я особенно приветствую некоторый опыт от людей, переключившихся на один из продуктов.

Использование extract & override, по-видимому, решает все проблемы при работе со старым унаследованным кодом, рефакторинг кажется чрезвычайно простым, а возможность появления ошибок кажется очень незначительной.Преимущество написания меньшего количества тестового кода?Более красивые классы с меньшим количеством виртуальных защищенных вещей?Прямо сейчас я не «понимаю», хотя понимаю, что очень полезно сначала тестировать частные методы изолированно, так как публичные методы могут быть слишком большими в таких старых устаревших кодовых базах.

Если выне знаю, что такое экстракт и переопределение: см. здесь .

1 Ответ

2 голосов
/ 18 августа 2011

Существует много различий между фреймворками, которые не относятся к технологии, на которой построены фреймворки.

Например:

  • API - каждый фреймворк имеет разные нотации и значения по умолчанию (например, строгие значения по умолчанию против смягченных значений по умолчанию)
  • Поддержка - собственные структуры обычно предлагают поддержку с лицензиями
  • Цена - это не вопрос использования, но требует бюджета

Основным преимуществом Extract & Override является то, что он требует некоторого рефакторинга. Если пренебречь кодом, над которым вы работаете, это дает хороший шанс просмотреть его и реорганизовать в сторону лучшего кода, а не только для тестируемости.

Основным преимуществом использования инфраструктуры Isolation является то, что вам не нужно изменять тестируемый код (если это большая кодовая база, может потребоваться много времени, чтобы просто реорганизовать ее для тестируемости). Кроме того, платформы Isolation не навязывают вам конкретный дизайн, это может быть полезно, если унаследованный код лучше соответствует существующему дизайну. Другая функция, которая полезна в унаследованном коде, - это замена экземпляров, созданных в тестируемом коде, обычно рефакторинг экземпляров требует больше усилий, и это можно сохранить. Последнее, что нужно - это подделка стороннего кода - используя изолирующие фреймворки, вы можете изолировать код, который не принадлежит вам, без использования классов-оболочек.

Отказ от ответственности - я работаю в Typemock

...