Pull to refresh

Comments 13

Спасибо за статью!

Не совсем понятно зачем VS в названии, кто-то склонен заменять одно другим?
В одном аспекте контракты и юнит тесты пересекаются: и то, и другое служит для выражения намерений кода. Но если у контрактов это, по сути, единственная задача, то юнит тесты успешно решают ряд других задач.

VS в заголовке имеет место, поскольку эта заметка является ответом на вопрос одного из моих коллег, который выразил мысль, что при наличии юнит-тестов постусловия становятся не нужными, поскольку они будут четко следовать из того, что мы ожидаем на выходе наших классов и что мы, собственно, assert-им.
Под «non-nullable reference типами» вы подразумеваете ссылки С++?
Да, нечто подобное. Хотя более близкое понятие есть в упомянутом выше Eifell-e (в нем, по умолчанию переменной реф. Типа просто нельзя присвоить Void, для этого есть специальная нотация: грубо говоря:

String s; // присвоить null нельзя String! s; // присвоить null можно

Аналогичные конструкции есть практически во всех функциональных языках, включая F# с его options (http://msdn.microsoft.com/en-us/library/dd233245.aspx)
В Spec#-е и правда есть, а в C# есть только nullable value type, но нет non-nullable reference типов.
А существуют способы ассоциировать ContractClassForAttribute с набором тестов (стандартные)? Грубо, если класс награжден контрактом, то для него среда тестирования автоматически вызовет 1,2,3… тесты. Ну или с минимальными усилиями хотябы — пишим тест с телом одну строку? типа ContractClassForAttribute.Assert(()=>new AAA()).
Не до конца отформатировал сообщение. Отправил раньше времени. Sory.
Нечто подобное умеет делать pex. Эта штука умеет генерировать параметризованные юнит тесты анализируя утверждения в теле класса.
К сожелению, не дождался ответа на свой вопрос, поэтому продолжаю свою мысль. Подход совмещения контрактов с юнит тестами напоминает вариант построения тестов на тестируемом классе. То есть, некоторый класс A содержит не только полезный функционал, но и тесты проверяющие его. Недостаток такого подхода очевиден — слишком много кода в классе.

Перед переходом на TDD, я пользовался контрактам. Тогда они были достаточно архаичными — System.Debug.Assert. Доходило до смешного — рядом с двумя строчками полезного кода распологался десяток Assert-ов. Два три экрана кода, при удалении «мусора» превращались в пол экрана.

Я потому и спрашивал. Может контракты и правда жизнеспособны? Разбиваем 100500 тестов на группы. Называем каждую из них «контрактом». Награждаем ими конкретные классы (хоть десять контрактов на один класс). В тестах запускаем проверку Типа на соответствие всем его контрактам. Как частный случай проверки, может сработать.
Извините, что не по теме, но нынче на Хабре за кросспосты не банят?
Sign up to leave a comment.

Articles