Какие-либо команды, там использующие TypeMock? Действительно ли это стоит огромной цены? [закрытый]
2 ответа
В проекте, над которым я работаю, много месяцев использовался TypeMock. На самом деле мы только что закончили полностью отказываться от него в пользу Moq (полностью бесплатный фреймворк для фиксации с лицензией Apache 2.0). Вам обязательно стоит заглянуть в Moq, если вы его не видели. В дополнение к самому интуитивному синтаксису любого инструмента для имитации, который я видел, вы получаете преимущества проверки типов во время компиляции. Очень хорошо.
На мой взгляд, TypeMock имеет одно существенное преимущество перед Moq. А именно может издеваться над чем угодно. Это включает в себя запечатанные классы, не виртуальные методы, конкретные типы и многое другое, что вы можете на это бросить. Если вы работаете с ASP.Net и в зависимости от того, как структурирован ваш код, это может фактически сделать возможной имитацию кода ASP.Net за классами. Довольно аккуратно.
Однако - мы обнаружили, что если вы хорошо структурируете свой код, преимущества TypeMock не перевешивают его цену. Кроме того, если вы не можете издеваться над чем-то с помощью Moq, это, вероятно, означает, что там есть запах. TypeMock позволяет вам лениться, и я думаю, что в результате может пострадать код. Moq и другие подобные им фреймворки (на ум приходит RhinoMocks) действительно заставляют задуматься о своем коде во время его написания, особенно с точки зрения тестируемости, но я бы сказал, что это хорошо :) Далее наша команда обратилась к несколько головных болей при попытке развернуть TypeMock на нашем сервере непрерывной интеграции.
Короче говоря, TypeMock - очень мощный инструмент. Как вы упомянули, для модульного тестирования старого устаревшего кода не так много продуктов лучше. Однако за 1000 баксов вы получаете одну лицензию TypeMock ИЛИ пару лицензий resharper, почти десять TD.Сетевые лицензии, новый сервер непрерывной интеграции и многое другое. Мой собственный опыт подсказывает, что оно того не стоит, но ваш пробег может отличаться!
+1 Ответ Эрика - полностью согласен.
Это похоже на механизм частных аксессоров MSTest - есть очень большая вероятность, что вы неправильно рассматриваете проблему. Если вам придется использовать какой-то технический МакГайвери, чтобы что-то протестировать, значит, кто-то делает что-то не так.
Конечно, следующее, что приводится в качестве контрапункта, - это то, что бывают случаи, когда кто-то уже сделал что-то не так (да, я смотрю на вас, SharePoint, WebForms и друзей), и вам действительно нужно сделать какой-нибудь комплекс, чтобы разобраться в ситуации, которая есть сейчас.
Подобные сражения часто могут быть огромной потерей времени, что, оглядываясь назад, редко заставляет вас чувствовать себя хорошо. Это похоже на высказывание «Ооо, мне определенно нужно пройти какое-то тестирование, и единственное, что будет работать, - это автоматизация пользовательского интерфейса, в зависимости от того, где мы находимся». Идя по этому пути:
отвлекает энергию от реального решения реальной проблемы - получения надлежащего тестирования всех форм и степени детализации с течением времени и столкновения с тем фактом, что есть много работы, которую нужно сделать, и методы, которые нужно изучить на пути к созданию системы, с которой вы можете чувствовать себя комфортно, учитывая исходную точку Legacy - 97.92% проектов начинаются или имеют тенденцию к достижению различных стадий
, оставляя вас с набором «Закодированных тестов пользовательского интерфейса», который вам не понравится.
Еще одна вещь - у MSR есть проект Moles, которым они были Pimping в последнее время, который делает то же самое, что и TM, то есть переписывает время выполнения с помощью хуков профилировщика. Может быть полезно для людей, которые чувствуют, что они хотят / нуждаются в чем-то в своем арсенале в качестве резервной копии, если вам когда-нибудь действительно не хватит дороги с Moq в реальном сценарии, из которого вы не можете реорганизовать свой путь и в конечном итоге окажетесь в лучшем месте. .