Comments 13
Спасибо за статью!
Не совсем понятно зачем VS в названии, кто-то склонен заменять одно другим?
Не совсем понятно зачем VS в названии, кто-то склонен заменять одно другим?
В одном аспекте контракты и юнит тесты пересекаются: и то, и другое служит для выражения намерений кода. Но если у контрактов это, по сути, единственная задача, то юнит тесты успешно решают ряд других задач.
VS в заголовке имеет место, поскольку эта заметка является ответом на вопрос одного из моих коллег, который выразил мысль, что при наличии юнит-тестов постусловия становятся не нужными, поскольку они будут четко следовать из того, что мы ожидаем на выходе наших классов и что мы, собственно, assert-им.
VS в заголовке имеет место, поскольку эта заметка является ответом на вопрос одного из моих коллег, который выразил мысль, что при наличии юнит-тестов постусловия становятся не нужными, поскольку они будут четко следовать из того, что мы ожидаем на выходе наших классов и что мы, собственно, assert-им.
Под «non-nullable reference типами» вы подразумеваете ссылки С++?
Да, нечто подобное. Хотя более близкое понятие есть в упомянутом выше Eifell-e (в нем, по умолчанию переменной реф. Типа просто нельзя присвоить Void, для этого есть специальная нотация: грубо говоря:
Аналогичные конструкции есть практически во всех функциональных языках, включая F# с его options (http://msdn.microsoft.com/en-us/library/dd233245.aspx)
String s; // присвоить null нельзя
String! s; // присвоить null можно
Аналогичные конструкции есть практически во всех функциональных языках, включая F# с его options (http://msdn.microsoft.com/en-us/library/dd233245.aspx)
А существуют способы ассоциировать ContractClassForAttribute с набором тестов (стандартные)? Грубо, если класс награжден контрактом, то для него среда тестирования автоматически вызовет 1,2,3… тесты. Ну или с минимальными усилиями хотябы — пишим тест с телом одну строку? типа ContractClassForAttribute.Assert(()=>new AAA()).
Не до конца отформатировал сообщение. Отправил раньше времени. Sory.
Нечто подобное умеет делать pex. Эта штука умеет генерировать параметризованные юнит тесты анализируя утверждения в теле класса.
К сожелению, не дождался ответа на свой вопрос, поэтому продолжаю свою мысль. Подход совмещения контрактов с юнит тестами напоминает вариант построения тестов на тестируемом классе. То есть, некоторый класс A содержит не только полезный функционал, но и тесты проверяющие его. Недостаток такого подхода очевиден — слишком много кода в классе.
Перед переходом на TDD, я пользовался контрактам. Тогда они были достаточно архаичными — System.Debug.Assert. Доходило до смешного — рядом с двумя строчками полезного кода распологался десяток Assert-ов. Два три экрана кода, при удалении «мусора» превращались в пол экрана.
Я потому и спрашивал. Может контракты и правда жизнеспособны? Разбиваем 100500 тестов на группы. Называем каждую из них «контрактом». Награждаем ими конкретные классы (хоть десять контрактов на один класс). В тестах запускаем проверку Типа на соответствие всем его контрактам. Как частный случай проверки, может сработать.
Перед переходом на TDD, я пользовался контрактам. Тогда они были достаточно архаичными — System.Debug.Assert. Доходило до смешного — рядом с двумя строчками полезного кода распологался десяток Assert-ов. Два три экрана кода, при удалении «мусора» превращались в пол экрана.
Я потому и спрашивал. Может контракты и правда жизнеспособны? Разбиваем 100500 тестов на группы. Называем каждую из них «контрактом». Награждаем ими конкретные классы (хоть десять контрактов на один класс). В тестах запускаем проверку Типа на соответствие всем его контрактам. Как частный случай проверки, может сработать.
И ни слова про LSP…
Вот тут, не?
sergeyteplyakov.blogspot.com/2012/02/lsp.html
sergeyteplyakov.blogspot.com/2012/02/lsp.html
Извините, что не по теме, но нынче на Хабре за кросспосты не банят?
Sign up to leave a comment.
Контракты vs Юнит тесты