Комментарии 18
Посмотрел, спасибо. Очень интересно.
0
Интересно, спасибо!
0
Тут, скорее, показан синтаксис TDD. На таком маленьком проекте мне очень сложно представить принцип TDD. Гораздо понятнее было бы показать это на серьезном проекте, который бы выполнял какую-то поставленную задачу. Можно даже не в коде это делать, а рисовать картинками, скажем, в UML.
В чем я вижу сейчас свою проблему, как начинающего программиста, который не работал еще ни над одним серьезным проектом, так это в том, что везде (книги, статьи и т.д.) показывают суть всех технологий на очень маленьких примерах, в которых сложно понять, для чего, в реальности, создавали ту или иную технологию, какие проблемы вставали перед разработчиками до того, как была придумана технология. И вот чем крупнее (в смысле масштаба проекта, в котором она должна использоваться) технология, тем сложнее сделать шаг через барьер понимания технологии и понимания того, где правильно ее использовать.
Вот и в этой теме хотелось бы пройти путь разработчика от начала и до конца. Видеть, какие задачи перед ним встают и как он их решает методом TDD.
В чем я вижу сейчас свою проблему, как начинающего программиста, который не работал еще ни над одним серьезным проектом, так это в том, что везде (книги, статьи и т.д.) показывают суть всех технологий на очень маленьких примерах, в которых сложно понять, для чего, в реальности, создавали ту или иную технологию, какие проблемы вставали перед разработчиками до того, как была придумана технология. И вот чем крупнее (в смысле масштаба проекта, в котором она должна использоваться) технология, тем сложнее сделать шаг через барьер понимания технологии и понимания того, где правильно ее использовать.
Вот и в этой теме хотелось бы пройти путь разработчика от начала и до конца. Видеть, какие задачи перед ним встают и как он их решает методом TDD.
+4
Тестинг как раз должен оставаться простым.
В больших проектах, тесты почти не отличаются от небольших примеров,
за исключением того, что приходиться мокать очень много связанных объектов.
В больших проектах, тесты почти не отличаются от небольших примеров,
за исключением того, что приходиться мокать очень много связанных объектов.
0
Если я буду создавать БОЛЬШОЕ приложение, то на это уйдет гораздо больше 40 минут :) Я могу вам посоветовать следить за развитием крупных проектов с открытым исходным кодом. Сейчас таких очень много. В нашей команде большой популярностью пользуется NHibernate.
+1
Я имел ввиду чисто схематически создавать. Если бегло говорить, то можно управиться и быстрее.
0
Вся идея TDD базируется на том, что проектирование кода идет в тесте. Если я буду рисовать UML диаграммы, то это абсолютно ничего не даст. Нет смысла рассуждать о сущностях в квадратиках, когда можно просто написать тест с их участием и посмотреть как они себя ведут сразу в коде.
Вот здесь довольно известный пример www.objectmentor.com/resources/articles/xpepisode.htm
Вот здесь довольно известный пример www.objectmentor.com/resources/articles/xpepisode.htm
+1
Спасибо большое, очень просто и наглядно. Смело скажу, что именно видео и живая демонстрация подтолкнуло(ёт?) меня на использование TDD в своих новых проектах.
Единственное я не сильно понял смысл IoC. Вы сказали, что в одной строчке (в конструкторе) захардкоживается все инъекции. После того, как вы ипользовали ninject связи остались захардкожеными, но уже в другой строчке (с лямбдами). Мне, как человеку не знакомому с IoC выйгрышь совсем не очевиден. Не могли бы Вы так же лаконично и просто уточнить, в чём приемущество?
Спасибо.
Единственное я не сильно понял смысл IoC. Вы сказали, что в одной строчке (в конструкторе) захардкоживается все инъекции. После того, как вы ипользовали ninject связи остались захардкожеными, но уже в другой строчке (с лямбдами). Мне, как человеку не знакомому с IoC выйгрышь совсем не очевиден. Не могли бы Вы так же лаконично и просто уточнить, в чём приемущество?
Спасибо.
0
НЛО прилетело и опубликовало эту надпись здесь
Я понял ваши опасения. Дело в том, что это не функцию API приложения, а название теста. Название теста должно говорить о том, что в этом тесте происходит. Я даже больше могу вам сказать, очень популярна подобная запись:
send_special_report_to_administrator_if_no_reports_created
send_special_report_to_administrator_if_no_reports_created
+3
А почему нет, я пишу на RubyOnRails и иногда получаются очень длинные названия методов созданые динамически и routes — например update_multiple_admin_user_accounts_path по мне так вполне нормальная практика, если она необходима.
0
Добрый день!
А как Вы тестируете работу по взаимодействию с объектами БД, с АД. Что для этого надо применять?
В Вашем блоге видел следующие ссылки:
blog.byndyu.ru/2010/01/tdd.html
blog.byndyu.ru/2009/04/blog-post.html
Но ясности они не принесли.
А как Вы тестируете работу по взаимодействию с объектами БД, с АД. Что для этого надо применять?
В Вашем блоге видел следующие ссылки:
blog.byndyu.ru/2010/01/tdd.html
blog.byndyu.ru/2009/04/blog-post.html
Но ясности они не принесли.
0
Привет, Александр. Спасибо за скринкаст!
У меня такой вопрос: какие приемущества нам дает разделение фреймворка на домен и бизнес логику?
У меня такой вопрос: какие приемущества нам дает разделение фреймворка на домен и бизнес логику?
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Видео. Пример разработки приложения с помощью TDD