Comments 24
TDD — test-driven development?
не подскажете, чем Rhino Mocks лучше Moq?
Не подскажу.
Это мой первый опыт использования подобных библиотек, я не выбирал сам, а использовал то, что мне порекомендовали. Для меня её главным достоинством было наличие рядом человека, к которому, при случае, можно обратиться с вопросом. Впрочем, это не понадобилось, все оказалось достаточно просто, хватило официальной документации.
Это мой первый опыт использования подобных библиотек, я не выбирал сам, а использовал то, что мне порекомендовали. Для меня её главным достоинством было наличие рядом человека, к которому, при случае, можно обратиться с вопросом. Впрочем, это не понадобилось, все оказалось достаточно просто, хватило официальной документации.
Думаю дело вкуса. Он старше и много людей его используют и развивают. Лично я предпочитаю moq, т.к. мне больше нравится его синтаксис, в сравнении с autofac в том числе. C moq лично у меня были траблы:
1. Неудобно когда биндится ответ для метода с out параметром.
2. Цепочка ответов которая прерывается Throw (если надо расскажу подробнее, может это я, что-то не понял).
3. Нету автобиндинга свойств моками. К примеру есть в autofac аля builder.RegisterType().PropertiesAutowired();
Но я считаю это мелочами, в остальном функционал схож, и синтаксис и простота moq для меня определили выбор.
1. Неудобно когда биндится ответ для метода с out параметром.
2. Цепочка ответов которая прерывается Throw (если надо расскажу подробнее, может это я, что-то не понял).
3. Нету автобиндинга свойств моками. К примеру есть в autofac аля builder.RegisterType().PropertiesAutowired();
Но я считаю это мелочами, в остальном функционал схож, и синтаксис и простота moq для меня определили выбор.
У меня на Moq не получилось переопределить виртуальный метод у класса. Rhino справился. Может конечно я не знаю как. А так, использование Moq немного удобнее. ИМХО, конечно
Собственно все это описано (про первые впечатления и изменения сроков разработки/отладки) в любой книге про TDD, но в более подробной и понятной форме. Чтобы комментарий полезный был, оставлю 3 хорошие книги по TDD:
— Кент Бек: Экстремальное программирование: разработка через тестирование
— Roy Osherove: The Art of Unit Testing: With Examples in .Net
— Steve Freeman: Growing Object-Oriented Software, Guided by Tests.
— Кент Бек: Экстремальное программирование: разработка через тестирование
— Roy Osherove: The Art of Unit Testing: With Examples in .Net
— Steve Freeman: Growing Object-Oriented Software, Guided by Tests.
Рекомендую книгу Кента Бека «Extreme Programming».
Ответит на многие вопросы по юнит тестам
Ответит на многие вопросы по юнит тестам
А я порекомендую книгу GOOS как современный пример создания полноценного приложения (с гуём и работающего с сетью) исключительно с использованием подхода TDD.
Пусть даже на TDD будет уходить больше времени, если разработчик тестирует свой код, то он отвечает за свою работу. Ну и конечно, чем больше практиковаться, тем меньше это будет занимать времени.
Я смотрю, здесь все видные гуру в тестировании :-)
Собственно, пост, адресовался тем, кто, как и я, только осваивает этот необъятный айсберг. Было бы крайне приятно услышать мнение тех, для кого использование принципов TDD еще не является неотделяемой частью характера.
Собственно, пост, адресовался тем, кто, как и я, только осваивает этот необъятный айсберг. Было бы крайне приятно услышать мнение тех, для кого использование принципов TDD еще не является неотделяемой частью характера.
Выходите на следующий уровень Behavior Driven Development. Почему думал, что он Behavior Driven Design. Википедия утверджает, что все-таки Development.
Record Replay — это старое говнище, которое юзали до появления линка.
Используйте синтаксис Arrange Act Assert — так значительно понятнее и носорожий мок его поддерживает.
Используйте синтаксис Arrange Act Assert — так значительно понятнее и носорожий мок его поддерживает.
Не считайте меня снобом, но описаное не TDD.
1. Тесты (или тест?) после кода
2. Тесты не как не повлияли на построение архитектуры, она целиком была сделана на бумаге. Driving-а (да и Design-а тоже) из аббревиатуры TDD нет
3. Нет и намека о ритме
4. Второй описанный (возможно, другие не были описанные) — точно не UnitTest. Или это небыл тест? Тогда sorry.
С использованием автотестирования — да. Но не TDD.
Но основной тезис «Тест – это не дополнение к коду, но его важная часть» классный.
1. Тесты (или тест?) после кода
2. Тесты не как не повлияли на построение архитектуры, она целиком была сделана на бумаге. Driving-а (да и Design-а тоже) из аббревиатуры TDD нет
3. Нет и намека о ритме
4. Второй описанный (возможно, другие не были описанные) — точно не UnitTest. Или это небыл тест? Тогда sorry.
С использованием автотестирования — да. Но не TDD.
Но основной тезис «Тест – это не дополнение к коду, но его важная часть» классный.
Безусловно, то что я тут написал не является классическим трудом по TDD :-)
Да и себя к мастерам тестирования я не отношу, хотя стараюсь двигаться в этом направлении.
Цель поста не описать очередной раз методологию, скрывающуюся за аббревиатурой TDD — про это как раз довольно много написано. Я хотел сформулировать мотивацию и преимущества применения автоматизированных тестов для разработчика даже на самых простых задачах.
Когда начинающему (да и опытному тоже) разработчику ставится задача, он быстренько выдает рабочий код и говорит что все сделал. Ты у него спрашиваешь, а как там дела с тестами для этого кода — он делает честные круглые глаза и говорит, что да, конечно, как только будет время, сразу же напишет. И все ясно, что это «потом» не наступит, скорее всего, никогда. И как его замотивировать и объяснить необходимость тестов — было совершенно непонятно (доводы, что если ты напишешь тесты сейчас, то в некотором гипотетическом будущем кому-то будет легче работают плохо :-( ).
Собственно, в упомянутом проекте (задача простая, а сроки более чем не жесткие — редкая удача) я ставил перед собой цель освоить использование моков и выработать некоторые методические принципы. Что и привело к появлению понравившегося вам тезиса. Его я считаю главным посылом для начала движения в сторону TDD (в классическом понимании).
Ведь главное — это начать, дальше можно развиваться и совершенствоваться бесконечно.
Да и себя к мастерам тестирования я не отношу, хотя стараюсь двигаться в этом направлении.
Цель поста не описать очередной раз методологию, скрывающуюся за аббревиатурой TDD — про это как раз довольно много написано. Я хотел сформулировать мотивацию и преимущества применения автоматизированных тестов для разработчика даже на самых простых задачах.
Когда начинающему (да и опытному тоже) разработчику ставится задача, он быстренько выдает рабочий код и говорит что все сделал. Ты у него спрашиваешь, а как там дела с тестами для этого кода — он делает честные круглые глаза и говорит, что да, конечно, как только будет время, сразу же напишет. И все ясно, что это «потом» не наступит, скорее всего, никогда. И как его замотивировать и объяснить необходимость тестов — было совершенно непонятно (доводы, что если ты напишешь тесты сейчас, то в некотором гипотетическом будущем кому-то будет легче работают плохо :-( ).
Собственно, в упомянутом проекте (задача простая, а сроки более чем не жесткие — редкая удача) я ставил перед собой цель освоить использование моков и выработать некоторые методические принципы. Что и привело к появлению понравившегося вам тезиса. Его я считаю главным посылом для начала движения в сторону TDD (в классическом понимании).
Ведь главное — это начать, дальше можно развиваться и совершенствоваться бесконечно.
Не используйте replay, это моветон. Проверять нужно состояние, не поведение
Sign up to leave a comment.
Test Driven Design — первый опыт внедрения