2010-03-24 3 views
0

Это я вернусь к основам с TDD для обучения.Как проверить, что поле является строкой

я первоначально реализован Person.Surname в поле типа объекта (простейший из возможных способов прохождения теста.

Затем я добавил тест настройки Person.Surname о том, что возвращаемое значение должно быть строкой и установить Person.Surname=20.

я «фиксированный» тест путем изменения реализации использовать string, а не object. тест уже давно компилирует из-за статическую проверку типов, так что я заметил это.

Person.Surname поля в настоящее время реализуется как строка. Если я изменил реализацию поля на объект, ни один из моих тестов не завершился.

Таким образом, я не оставил своего намерения в тесте. Есть ли способ провести неудачный тест в этом случае?


Update: Я согласен с Esko, что практически это не то, что вы хотите делать. С точки зрения обучения точка, которую я пыталась сделать, заключалась в том, что если я (или кто-то другой в более поздний момент времени) расширяет область видимости моего поля (скажем, от строки к объекту), у меня не будет никаких непосредственно сбойные модульные тесты. Может быть, это не плохо?

+0

Если вы измените поле или выполните другой рефакторинг, иногда это приведет к сбою некоторых тестов. Затем вам нужно выяснить, почему тест терпит неудачу и исправить его, обновив производственный код (если последнее изменение просто что-то сломало) или путем обновления тестового кода (если он был сломан, но намерение позади теста остается прежним) или иногда путем удаления теста (если намерение за тестом не является более своевременным). И чтобы узнать, зачем было написано тест, полезно, чтобы тесты описывали функции, как я упоминал в своем ответе. –

ответ

5

Письменные тесты о поле, имеющем некоторый тип, слишком l ow абстракции. Напишите тесты, которые describe features. Затем тесты лучше описывают, почему код был написан, и вы сможете более свободно реорганизовывать реализацию, не нарушая/недействительно существующие тесты.

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

0

не могли бы вы добавить проверку, как:

Assert.AreEqual(typeof(string), Person.Surname.GetType()); 
0

вы можете использовать это оператор ....

if (Person.Surname is string) 
{ 
    // do stuff 
} 

вы можете также использовать в качестве оператора ...

string surname = Person.Surname as string; 
if (surname != null) // as succeded 
{ 
    // do stuff 
} 
1
Assert.IsInstanceOfType(Person.Surname, typeof(string)); 
+0

Если поле реализовано как строка, это, очевидно, всегда пройдет. Если поле реализовано как объект, это все равно пройдет, если строка будет сохранена в поле (потому что строка наследуется от объекта). Если вы напишете инициализирующий тест фамилию на int, когда элемент реализован как объект, тогда тест завершится с ошибкой. Однако как только вы исправите тест, изменив тип поля на строку, тест больше не будет компилироваться из-за проверки типа. – AndyM

Смежные вопросы