Друзья, мы все читали книги про TDD и знаем как красиво написать калькулятор, используя эту мощную инженерную практику. Но, интересно другое. В рамках данной темы поделитесь, пожалуйста, своим практическим опытом (или конструктивными ссылками) применения TDD для Web-приложений? Для меня здесь не очевидным являются следующие аспекты:
1) В подавляющем большинстве, Web-проекты, которые мы разрабатываем, имеют минимальное количество бизнес-логики. В основном это CRUD-странички, т.е. Web-проекты состоят из логики доступа к данным (которая не тестируется Unit-тестами и заменяется Mock-объектами) и презентационной логики (которую, на мой взгляд, логичнее тестировать инструментами типа Selenium в рамках интеграционных UI-тестов). Т.е. получается, что оправданное покрытие проекта такого рода Unit-тестами будет минимальным. Например, мы сможем оправдать затраты времени на разработку Unit-теста для алгоритма расчета рейтинга пользователя, при этом, для остальных 99% кода Unit-тесты писать нет смысла, поскольку это просто логика извлечения и сохранения данных в БД. Не теряется ли при этом главный смысл и профиты TDD?
2) Я понимаю почему хорошо покрытие Unit-тестами презентационной логики CRUD-страниц для интерпретируемых языков программирования — они позволяют Вам обнаруживать синтаксические ошибки до выкладки кода на сервер. Наша компания использует компилируемые языки программирования — Java (JSF2) и C#(ASP.NET MVC2) и данный аспект мы отлавливаем без модульных тестов как непосредственно на машине разработчика, так и на сервере непрерывной интеграции. Чем еще может быть оправдано 90-100% покрытие кода Web-приложений модульными тестами для компилируемых языков программирования в Web-проектах?
3) В качестве важной особенности TDD был озвучен такой существенный аспект как продумывание и проектирование дизайна (API) приложения до начала написания кода его имплементации. В наших командах разработчиков мы используем методологию Scrum. На планировании, после того как мы уяснили суть задачи в бизнес-терминах, мы разбиваем задачу на ряд небольших технических подзадач, каждую из которых мы четко понимаем как делать и сколько это займет времени. Т.е. на этом этапе мы уже имеем достаточно низкоуровневый дизайн: знаем какие основные классы, методы и шаблоны мы должны разработать для реализации задачи. Имеет ли смысл при этом тратить время на разработку модульных тестов, которые, как Вы знаете, съедают практически столько же времени, сколько разработка собственно самого функционала?
4) Современные среды разработки дают нам инструменты, позволяющие проводить смелый рефакторинг кода, а наличие интеграционных тестов (например, Selenium) на ПК разработчика и на CI-сервере дает уверенность в том, что ничего точно не отвалилось в процессе. Так что данный аспект тоже является для меня не убедительным.
Поймите правильно, я вовсе не отпариваю ценность таких инженерных практик как TDD, где-то они просто незамеными. Например, в корпоративных и банковских приложениях со сложными workflow. А я просто пытаюсь обосновать для себя эффективность ее применения в моем конкретном случае при разработке Web-проектов средней сложности.
Если у кого-нибудь есть опыт и\или соображения на эту тему — буду рад конструктивному диалогу. Спасибо!
Конечно, на ответы влияет шумиха вокруг технологии. Все говорят, что это хорошо для веба и поэтому люди так отвечают. Хотя ответы о перспективах тех, кто уже пользуются не сильно отличаются от тех, кто только слышал. Но ответов слишком мало, чтобы ещё и подгруппы сравнивать.
Вообще говоря — да. На западе salesforce наторговал на 1.3 млрд. долларов. Но возможно в России своя специфика — все боятся за свои данные, хотя опрос этого не подтвердил (вопрос про минусы облачного хостинга).
На всех графиках приведены проценты от числа ответивших на данный вопрос.
Выровнять результаты под 100% можно легко, для этого нужно разделить каждый процент на сумму всех процентов на графике. Но вот количество информации о том, что отвечали люди, при этом уменьшится, так как назад пересчитать уже нельзя.
95% опрошенных знают компанию Amazon и 80% знают компанию Google. 100% не получается, но это нормально. С услугами то же самое, из приведённых данных получается именно востребованность услуг, как я её понимаю. В случае 40 из 50 понятно, что 80% пользователей покупают одно и 80% другое. Доли рынка посчитать нельзя, но это и понятно, ведь не было вопросов про деньги, которые тратятся на эти услуги. Если это интересно, то можно сделать другой опрос, только будет ли много ответов.
Поделитесь, пожалуйста, опытом, как красиво интегрировать TeamCity-SVN-JIRA так, чтобы номер тега в SVN при успешной сборке билда становился бы сразу «видным» в JIRA в виде отдельного поля «build version». Идея в том, чтобы закрывать таски с JIRA с указанием номера сборки, в которой этот таск (баг) был закрыт. Нужно для тестировщиков. Если есть альтернативные мысли как связать сборки и таски, буду рад Вашим мыслям.
Друзья, а поделитесь, пожалуйста, опытом, как красиво интегрировать TeamCity-SVN-JIRA так, чтобы номер тега в SVN при успешной сборке билда становился бы сразу «видным» в JIRA в виде отдельного поля «build version». Идея в том, чтобы закрывать таски с JIRA с указанием номера сборки, в которой этот таск (баг) был закрыт. Нужно для тестировщиков. Если есть альтернативные мысли как связать сборки и таски, буду рад Вашим мыслям.
Все руки не доходят Dojo Dijit заменить на что-нибудь, корректно поддерживающее Оперу :(
А, кстати, почему у нас в России многие так Оперу любят? Около 30% пользователей, если не ошибаюсь, хотя в мире ее популярность на порядок ниже, около 3%.
Мы открыты для общения, поэтому, если Вы сформулируете конструктивные замечания/пожелания по юзабилити, то мы их сможем исправить/реализовать. Спасибо!
Некоторые участники еще присылают нам свои задания (у некоторых работодателей их несколько штук), так что если я сейчас опубликую список «ттх», то очень вероятно, что он окажется неполным. В любом случае, уверен, что регистрироваться стоит, это займет не более двух минут. До 28 сентября осталось совсем немного, тогда сразу все проясниться.
Для нас критерии выбора были следующие: известная компания, проявившая желание участвовать в чемпионате и приславшая нам адекватные задания, имеющая возможность стажировать и в последствии трудоустроить студентов-победителей. Вот как-то так.
Данный чемпионат — попытка ре инкарнации «Софтулийских игр», так что, можно сказать, что он относится к обеим категориям. Инвесторов мы не привлекаем, спонсоры предоставляют только призы для участников.
Добрый день! Задания будут состоять из двух частей: 1-разработка алгоритма, 2-его реализация. Каждый работодатель оценивает вес первой и второй часть задания сам (в тексте задания будет написано за что и сколько баллов из скольки будет начисляться). Платформы будут самые разные: PHP, Java, .NET, Oracle… это тоже зависит от условий задачи, поставленной самим работодателем. Для некоторых задач, платформа реализации значения не имеет. Большинство заданий — узкопрофильные, так как работодатели планируют брать победителей к себе на стажировку/работу и их, конечно, интересуют конкретные навыки.
1) В подавляющем большинстве, Web-проекты, которые мы разрабатываем, имеют минимальное количество бизнес-логики. В основном это CRUD-странички, т.е. Web-проекты состоят из логики доступа к данным (которая не тестируется Unit-тестами и заменяется Mock-объектами) и презентационной логики (которую, на мой взгляд, логичнее тестировать инструментами типа Selenium в рамках интеграционных UI-тестов). Т.е. получается, что оправданное покрытие проекта такого рода Unit-тестами будет минимальным. Например, мы сможем оправдать затраты времени на разработку Unit-теста для алгоритма расчета рейтинга пользователя, при этом, для остальных 99% кода Unit-тесты писать нет смысла, поскольку это просто логика извлечения и сохранения данных в БД. Не теряется ли при этом главный смысл и профиты TDD?
2) Я понимаю почему хорошо покрытие Unit-тестами презентационной логики CRUD-страниц для интерпретируемых языков программирования — они позволяют Вам обнаруживать синтаксические ошибки до выкладки кода на сервер. Наша компания использует компилируемые языки программирования — Java (JSF2) и C#(ASP.NET MVC2) и данный аспект мы отлавливаем без модульных тестов как непосредственно на машине разработчика, так и на сервере непрерывной интеграции. Чем еще может быть оправдано 90-100% покрытие кода Web-приложений модульными тестами для компилируемых языков программирования в Web-проектах?
3) В качестве важной особенности TDD был озвучен такой существенный аспект как продумывание и проектирование дизайна (API) приложения до начала написания кода его имплементации. В наших командах разработчиков мы используем методологию Scrum. На планировании, после того как мы уяснили суть задачи в бизнес-терминах, мы разбиваем задачу на ряд небольших технических подзадач, каждую из которых мы четко понимаем как делать и сколько это займет времени. Т.е. на этом этапе мы уже имеем достаточно низкоуровневый дизайн: знаем какие основные классы, методы и шаблоны мы должны разработать для реализации задачи. Имеет ли смысл при этом тратить время на разработку модульных тестов, которые, как Вы знаете, съедают практически столько же времени, сколько разработка собственно самого функционала?
4) Современные среды разработки дают нам инструменты, позволяющие проводить смелый рефакторинг кода, а наличие интеграционных тестов (например, Selenium) на ПК разработчика и на CI-сервере дает уверенность в том, что ничего точно не отвалилось в процессе. Так что данный аспект тоже является для меня не убедительным.
Поймите правильно, я вовсе не отпариваю ценность таких инженерных практик как TDD, где-то они просто незамеными. Например, в корпоративных и банковских приложениях со сложными workflow. А я просто пытаюсь обосновать для себя эффективность ее применения в моем конкретном случае при разработке Web-проектов средней сложности.
Если у кого-нибудь есть опыт и\или соображения на эту тему — буду рад конструктивному диалогу. Спасибо!
Выровнять результаты под 100% можно легко, для этого нужно разделить каждый процент на сумму всех процентов на графике. Но вот количество информации о том, что отвечали люди, при этом уменьшится, так как назад пересчитать уже нельзя.
95% опрошенных знают компанию Amazon и 80% знают компанию Google. 100% не получается, но это нормально. С услугами то же самое, из приведённых данных получается именно востребованность услуг, как я её понимаю. В случае 40 из 50 понятно, что 80% пользователей покупают одно и 80% другое. Доли рынка посчитать нельзя, но это и понятно, ведь не было вопросов про деньги, которые тратятся на эти услуги. Если это интересно, то можно сделать другой опрос, только будет ли много ответов.
А, кстати, почему у нас в России многие так Оперу любят? Около 30% пользователей, если не ошибаюсь, хотя в мире ее популярность на порядок ниже, около 3%.
www.liveinternet.ru/users/morav/post95395237/