Я знаю, что это почти двухлетний вопрос; но, глядя на исходный контекст вопроса, похоже, что @Anthony действительно хочет использовать MSpec в своих тестовых проектах.
Два ответа от @bitbonk и @mtijn дают веские причины, почему вы не должны никогда игнорировать их на уровне проекта. Но эти два ответа проигнорировали первоначальное намерение @Anthony, заключающееся в том, что он пытается использовать MSpec.
Видите ли, MSpec — это среда BDD, которая использует тяжелые определения делегатов и полей для определения ваших спецификаций. Часто у вас есть неназначенные поля и делегаты. Это приводит к тому, что предупреждения в VS летают как сумасшедшие, особенно если у вас есть StyleCop и другие инструменты автоматизации, чтобы держать разработчиков под контролем.
[Subject(typeof(PostService), "when_calling_Save()"]
class with_a_valid_Post_object
{
It should_save_to_repository;
It should_update_post_counter;
Behaves_like<Normal_Behaviors> a_PostService;
}
Хотите угадать, сколько предупреждений это только что вызвало? Хотя на самом деле совершенно нормально заблаговременно специфицировать свой код и проекты. Вас не должно раздражать куча предупреждений при спецификации BDD для вашего дизайна: весь смысл MSpec заключается в том, чтобы описать вашу общую историю в контексте с наименьшим количеством синтаксического шума. Предупреждения, сделайте это очень шумным после того, как вы создадите дюжину или около того историй с дюжиной или около того спецификациями каждая!
Теперь я вижу, как люди пытаются оправдать предупреждения, говоря: «Эй, теста еще нет, он просто заглушен! Предупреждения показывают, что нам нужно их реализовать». Ну, на самом деле, MSpec уже по-другому представляет эти «заглушенные» спецификации в окне «Вывод» во время работы, отмеченные как «Пропущенные» в итоговых результатах теста, а также довольно милые в своих выходных отчетах HTML. Другими словами, вам не нужны предупреждения, чтобы кричать на вас, что есть нереализованные спецификации, потому что бегуны уже делают это.
Behaves_like<T> уже немного странный. Но обратите внимание, что это все, больше нет реализации Behaves_like<T> behaviors к этому. Это просто неназначенное поле, которое использует бегун MSpec (все делегаты поля) и запускает их.
Итак, решение простое: для тестовых проектов MSpec «Specs», посвященных исключительно проектам Machine.Specifications, я часто щелкаю правой кнопкой мыши настройки проекта и добавляю их в поле «Подавить»:
0169;0649
Опять же, это только для тестовых проектов MSpec (или любой другой среды BDD C#, поскольку они используют тяжелые делегаты и неназначенные поля). Вы никогда не должны делать это для любого нормального проекта.
В качестве альтернативы, если руководитель вашей группы отказывает вам в праве редактировать его для вашего тестового проекта, вы можете просто реализовать свои спецификации, добавив к синаксическому шуму, которого вы пытались избежать в первую очередь с помощью MSpec (вините свою команду лид за усложнение вашей жизни "переключением контекста"!).
[Subject(typeof(PostService), "when_calling_Save()"]
class with_a_valid_Post_object
{
It should_save_to_repository =()=> { };
It should_update_post_counter =()=> { };
Behaves_like<Normal_Behaviors> a_PostService =()=> { };
}
Это гораздо более уродливо и действительно уводит вас от общей истории BDD, которую вы пытаетесь описать. Не говоря уже о том, что все ваши спецификации теперь будут приняты, ничего не реализовано (вы можете добавить еще больше, чтобы сделать это жестким сбоем, с throw new NotImplementedException() - но серьезно?). Но это способ «внедрить» каждое поле, если вы не хотите игнорировать их на уровне проекта.
person
eduncan911
schedule
24.07.2013
