Comments 18
Посмотрел, спасибо. Очень интересно.
Интересно, спасибо!
Тут, скорее, показан синтаксис TDD. На таком маленьком проекте мне очень сложно представить принцип TDD. Гораздо понятнее было бы показать это на серьезном проекте, который бы выполнял какую-то поставленную задачу. Можно даже не в коде это делать, а рисовать картинками, скажем, в UML.
В чем я вижу сейчас свою проблему, как начинающего программиста, который не работал еще ни над одним серьезным проектом, так это в том, что везде (книги, статьи и т.д.) показывают суть всех технологий на очень маленьких примерах, в которых сложно понять, для чего, в реальности, создавали ту или иную технологию, какие проблемы вставали перед разработчиками до того, как была придумана технология. И вот чем крупнее (в смысле масштаба проекта, в котором она должна использоваться) технология, тем сложнее сделать шаг через барьер понимания технологии и понимания того, где правильно ее использовать.
Вот и в этой теме хотелось бы пройти путь разработчика от начала и до конца. Видеть, какие задачи перед ним встают и как он их решает методом TDD.
В чем я вижу сейчас свою проблему, как начинающего программиста, который не работал еще ни над одним серьезным проектом, так это в том, что везде (книги, статьи и т.д.) показывают суть всех технологий на очень маленьких примерах, в которых сложно понять, для чего, в реальности, создавали ту или иную технологию, какие проблемы вставали перед разработчиками до того, как была придумана технология. И вот чем крупнее (в смысле масштаба проекта, в котором она должна использоваться) технология, тем сложнее сделать шаг через барьер понимания технологии и понимания того, где правильно ее использовать.
Вот и в этой теме хотелось бы пройти путь разработчика от начала и до конца. Видеть, какие задачи перед ним встают и как он их решает методом TDD.
Тестинг как раз должен оставаться простым.
В больших проектах, тесты почти не отличаются от небольших примеров,
за исключением того, что приходиться мокать очень много связанных объектов.
В больших проектах, тесты почти не отличаются от небольших примеров,
за исключением того, что приходиться мокать очень много связанных объектов.
Если я буду создавать БОЛЬШОЕ приложение, то на это уйдет гораздо больше 40 минут :) Я могу вам посоветовать следить за развитием крупных проектов с открытым исходным кодом. Сейчас таких очень много. В нашей команде большой популярностью пользуется NHibernate.
Я имел ввиду чисто схематически создавать. Если бегло говорить, то можно управиться и быстрее.
Вся идея TDD базируется на том, что проектирование кода идет в тесте. Если я буду рисовать UML диаграммы, то это абсолютно ничего не даст. Нет смысла рассуждать о сущностях в квадратиках, когда можно просто написать тест с их участием и посмотреть как они себя ведут сразу в коде.
Вот здесь довольно известный пример www.objectmentor.com/resources/articles/xpepisode.htm
Вот здесь довольно известный пример www.objectmentor.com/resources/articles/xpepisode.htm
Спасибо большое, очень просто и наглядно. Смело скажу, что именно видео и живая демонстрация подтолкнуло(ёт?) меня на использование TDD в своих новых проектах.
Единственное я не сильно понял смысл IoC. Вы сказали, что в одной строчке (в конструкторе) захардкоживается все инъекции. После того, как вы ипользовали ninject связи остались захардкожеными, но уже в другой строчке (с лямбдами). Мне, как человеку не знакомому с IoC выйгрышь совсем не очевиден. Не могли бы Вы так же лаконично и просто уточнить, в чём приемущество?
Спасибо.
Единственное я не сильно понял смысл IoC. Вы сказали, что в одной строчке (в конструкторе) захардкоживается все инъекции. После того, как вы ипользовали ninject связи остались захардкожеными, но уже в другой строчке (с лямбдами). Мне, как человеку не знакомому с IoC выйгрышь совсем не очевиден. Не могли бы Вы так же лаконично и просто уточнить, в чём приемущество?
Спасибо.
Я понял ваши опасения. Дело в том, что это не функцию API приложения, а название теста. Название теста должно говорить о том, что в этом тесте происходит. Я даже больше могу вам сказать, очень популярна подобная запись:
send_special_report_to_administrator_if_no_reports_created
send_special_report_to_administrator_if_no_reports_created
А почему нет, я пишу на RubyOnRails и иногда получаются очень длинные названия методов созданые динамически и routes — например update_multiple_admin_user_accounts_path по мне так вполне нормальная практика, если она необходима.
Добрый день!
А как Вы тестируете работу по взаимодействию с объектами БД, с АД. Что для этого надо применять?
В Вашем блоге видел следующие ссылки:
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
Но ясности они не принесли.
Привет, Александр. Спасибо за скринкаст!
У меня такой вопрос: какие приемущества нам дает разделение фреймворка на домен и бизнес логику?
У меня такой вопрос: какие приемущества нам дает разделение фреймворка на домен и бизнес логику?
Sign up to leave a comment.
Видео. Пример разработки приложения с помощью TDD