А в паттерне MVVM UI - презентейшен - это модель, а UI - это даже не View, а композиция мз стандартных контролов, предоставляемых фреймворком.. 
Давайте оставим паттерны в покое, поскольку мы говорим о инструментах.. 

Все время говорится о разделении UI от представления. Зачем? Не только обеспечить разделяемость разработки, но и обеспечить максимальную тестируемость продукта. При этом подразумевается, что все, что должно подлежать тестированию, должно уйти из UI. Точно так же, как и "(клиентский javascript)". Вычислительные скрипты должны быть вынесены из UI вообще. Ну а тестировать скрипты типа getElementById('btn1').style.visibility='hidden' ... ну уж увольте.. Если кнопка есть, она будет hidden... Я этому верю как аксиоме )) Каждые два часа проверять, не удалил ли кто-нибудь эту кнопку случайно?! Давайте не называть этот маразм методологией ))

В таком случае, что же тогда тестирование UI? Тестирование купленного фрейморка (стандартные контролы - часть фрейморка)? Разработчик не несет ответственность за фрейморк и заказчик всегда это знает. Он или согласен, чтобы этот фрейморк использовался в его продукте. Или нет... UI - это средство отображения состояния приложения. Мы же не тестируем такое средство отображения информации, как дисплей машины, когда пытаемся доказать клиенту, что мы сделали его продукт качественно? UI - средство взаимодействия с пользователем. Мы не тестируем клавиатуру и мышь...

Ну а если мы не можем обеспечить композитному глупому UI возможность работать только с элементарными типами данных, генерить только стандартные события... и ни о чем ни в коем случае не думать. То в этом случае нужно нанять нормального архитектора в компанию. Вот такое мое мнение о тестировании UI ))

В чем я согласен с Любителем
1. В его высказываниях об аджайле и тестировании
2. TDD - это зло. Я бы даже сказал - это фикция, убивание проектного времени и особенно - денег клиента
3. цитата " Хотя такой ситуации ИМХО просто не должно быть - надо писать в обратном порядке smile"  (сначала иногда делается прототипирование)
4. "Если планируется разработка или (особенно) переработка, затраная в архитектурном плане." - при этом тестировать нужно только интерфейсы взаимодействия модулей и слоев. Также, если слой достаточно сложен - тестировать нужно интерфейсы взаимодействия классов внутри слоя.
5. о QA и функциональных тестах.

tol05, К сожалению, в современных приложениях, в частности веб, тот самый клиентский скрипт (он же presentation logic), который ты считаешь тривиальным и незначительным, по объему значительно превышает BL. Если знаешь как "вынести их из UI вообще" - переселить на сервер - скажи, а то мужики то не знают  Возможно, в гугл или в твиттер надо позвать архитектора - а то они понаписывали сложного кода на javascript, ламеры. ;)
Composit UI с элементарными типами и стандартными CRUD событиями - это инструмент для data-driven intranet приложений. А в интернете сейчас в моде user-driven design, где поведение каждой кнопки приходится обдумывать.

Ну и вообще похоже что ты по UI подразумеаешь именно сами кнопочки и контролы, их действительно бессмысленно тестить. Я под UI подразумевал presentation layer, IMHO, это было достаточно очевидно из контекста. Сходи например, на MSDN, Designing the Components of an Application or Service, там Presentaion Layer состоит из UI Components и UI Process Components, как бы в подтверждение того что не только я так UI понимаю. В посленем App Arch Guide тоже. Может быть тебе стоит переосмыслить понятие UI?

В паттерне MVVM все три куска - это Presentation, т.е. UI в общепринятом смысле. 
 
О ТДД и прочем - да, согласие с тем, что ТДД надо строить не на функциональных тестах, вполне логично ведет к остальным пунктам. Там выше были мои аргументы по кажому из них, если не согласен - отпишись. Потому что пока (IMHO) твоя позиция - тесты вообще практически не нужны, что как бы противоречит здравому смыслу (опять же IMHO). Утверждение что тесты не нужны, или нужны, но только если "планируется" - просто следствие слишком большой самоуверенности разаработчика. Хотя, для интранет приложений, которые сдаются вникуда, без саппотра и развития - да, тесты не нужны.

Открой блог targetprocess (явно уважаемой тру-agile конторы), запись о процессе: http://www.targetprocess.com/blog/2009/10/...nt-process.html
Посмотри какое у них покрытие функциональными тестами, какое у них отношение к "ненужным" тестам UI.

Ну и опять же, убедить меня что тесты на UI не нужны, а TDD вредно - без шансов, потому что я могу сравнить результаты на схожих проектах с TDD и тестами на UI и без.

Ну и раз уж начали флудить, ты - разработчик? или РМ, архитектор, тимлид?

Это сообщение отредактировал(а) PashaPash - 15.11.2009, 01:57

PashaPash,
По поводу всего того, что Вы написали... Кроме web-based applications в мире существует большое колличество других типов ПО. 
Я всегда считал, считаю и буду считать, что самый главный минус в разработке приложений данного типа - это перегрузка граничного UI слоя всякого рода скриптами, желание угодить всем платформам и браузерам, а также нарастить usability данных приложений точечными включениями многочисленных платформ, чужеродных друг другу. Отсюда и чудовищный объем javascript-та. 

Однако, в последние годы, становится заметным (даже далекому от сферы разработки человеку) что даже для такого "трудного ребенка" как web-based applications делается все, чтобы облегчить UI слой, избавиться от скриптов. Уменьшить их, автоматизировать их создание и т.д. и т.п. Это и AJAX с его внутренними (не нуждающимися в своем тестировании) скриптами. И средства скриптогенерации. И Silverlight.. Кстати, последний вообще подразумевает отказ от всего того, что Вы называете современным и модным...

user-driven design - он не подразумевает скриптогенерацию? Кто будет писать те многочисленные скрипты, в тестировании которых Вы нуждаетесь каждый день?
Про паттерн MVVM - будем считать что Вы этого не писали... 

я в своих постах флуда не вижу. Ну а кто я... А разве это важно?!! Какое это может иметь значение для интернет community?
и в мыслях такого не было. Я все больше посты Любителя и Ивашки читал...

О том, что тесты не нужны, я не писал. Вниметельнее перечитайте текст.
Ок, объясню свою мысль яснее. Тесты  нужны только для проверки выполнения пунктов требований. Пока требования не написаны (на этапе прототипа например) - тесты не нужны. Когда требования написаны - тесты нужны. Когда требования меняются - тесты меняются. Дописываются, модифицируются и т.п.

Это сообщение отредактировал(а) tol05 - 15.11.2009, 12:03

tol05, да, мне тоже не нравится javascript и современный web. Но я не настолько верю в светлое будущее кодогенерации.
И, кстати, что будет служить источником для генерации? Просто интересно, почему так же нельзя сгенерировать бизнес-логику, и BL?

Мне вот, как не слишком далекому то сферы человеку, становится заметным что в последнее время все пытаются написать как можно больше логики UI именно на javasript. Ajax вообще подразумевает достаточно активную ручную работу с html  и dom. И в последние годы (гм) появляется много фреймворков, направленных на облегчение написания скрипта (а не выноса его и кодогенерации). Тот же jquery.

И как, интересно, эту проблему решит Silvelight? Да, Silverlight позволяет не писать скриптов, но Presentation Layer на SL - это все еще Presentation Layer (который UI). И если SL решает проблему, то почему до сих пор Flash не захатил web, ведь он так же способен ее решить?


Вообще-то не подразумевает, он подразумевает что логика UI не генерируется по данным. Ну и опять же скриптогенерацию из чего? Из описания логики UI, но на другом языке?
 

Ну зачем же. Я вот все еще уверен что MVVM, MVC, MVP - это паттерны организации Presentation Layer, и что все, кроме M в них - это presentation layer.

И, кстати, чтобы уж совсем не спорить - там выше на пару страницы упоминались не тесты UI. Там упоминались тесты из (посредством) UI. И, кстати, неавтомтизированные.

Не имеет, но цель топика - собрать инфу о процессах и инструментах, а не спорить и TDD и возможности кодогенерации UI. А для описания процесса (и для спора о TDD ;) важен контекст - роль спорящего, типы приложений, ориентация (custom/outsource/freelance), длительность (2-3 месяца, 2-3 года). А иначе - это как спорить с php-том о транзакциях.


И чем же тогда вредно TDD (при нефанатичном применении)? TDD вообще никак не противоречит написанному, IMHO. Даже наоборот, позволяет контролировать покрытие требований тестами. 
TDD - это когда тесты меняются чтобы соответствовать требованиям. А потом уже меняется код. Что в этом плохого?

Кстати, поделись процессом с тулзами. Интересно, насколько активно у вас используется кодогенерация ;)

Новый виток? Прикольно. Отвяжитесь вы от жаваскрипта. Он может представлять как UI так BL логику. Первую тестировать нет смысла, а вот вторую стоит. Для этого и фреймворки есть. Например в FireBug-е. Есть и масса других, но я этой темой не интересовался за ненадобностью.


Вот так бы и сказал. Обычно под этим понимают разные вещи.

Так я ж и сказал, чтобы прояснить ситуацию. Или ты не мое сообщение процитировал  Даже нашел исходное сообщение, там UI упоминается в контексте UI/BL/DAL, что, IMHO, позволяет однозначно понять что я подразумевал под UI. Там даже есть ссылки, почему именно я посмел обозвать Presentation - UI 
Осталось узнать что именно tol05 подразумевает под UI, т.к. мои сообщения он тупо не читает 


BL на JavaScript - вообще сомнительная вещь, вряд ли есть смысл переносить бизнес-логику в браузер, хотя бы из соображений безопасности. То, что ты подразумеваешь под BL на JavaScript, скорее всего называется UI process components, и он является частью UI. Это вполне однозначно сказано в Web Architecture Pocket Guide от производителя.

Отвязаться от JavaScript очень хочется, но, IMHO, невозможно вообще во всех случаях. Потому что в некоторых случаях отвязка от JS, кодогенерация, и перенос логики на сервер ведут к банальным тормозам в приложении. 

Весь спор как раз о том, стоит ли тестировать UI-логику. UI-логика может быть весьма нетривиальной. Я бы просто не был настолько категоричен, на уровне "нельзя в принципе". Все зависит от конкретного приложения, и от конкретной предметной области. Может быть тяжело представить сложную логику UI? Конктретный пример, из текущего проекта:
- в приложении есть диаграммы Ганта (типа как у Горбунова, улучшенные). 
- с drag'n'drop и прочими плюшками
- с относительно нетривиальной логикой именно на уровне Presentation (даже точнее, UI, если под ним весь Presentation не понимать)
- в требованиях явно прописано - они должны быть написаны полностью на стороне браузера
- в тех же требованиях - никакого silverlight.
- объемы данных - до 400 проектов, до 5000 тасков, + завязка еще на 5-6 сущностей, типа таймлогов 
- в требованиях - диаграммы должны работать быстро

Я пока не вижу других вариантов реализации, кроме как написать это все вручную (относительно, с использованием фреймворков), и написать код UI именно на JS. С компонетной моделью, шаблонизаторами и проч, но все равно на JS. И его придется тестировать, причем хотя бы часть - автоматически.

Требования довольно странные, но сводяться к одному - у конкурентов есть такой гант, а у нас - нет. И кроме такого вот принудительно-скриптового ганта есть еще более веселые куски.

Если гуру tol05 подскажет как "автосгенерировать" этот кусок, и при этом не получить тормоза и chatty-интерфейс на сервере, то я с радостью откажусь от тестирования UI в принципе.

На случай подхода "а вы напишите на silverlight" - в текущей версии гант как раз на silverlight, и именно его хотят переписать на JavaScript. Потому что бизнесу абсолютно пофиг на внутреннюю чистоту архитектуры, им продажи важны. Да, я полностью согласен вот с этим утверждением:


Но смысл его - главный минус в разработке веб приложений - то, что они веб. Или только я так его понимаю?

Пока чистые, не rich-client, веб-приложения востребованы - мы вынуждены их писать. 
Вообще обсуждение пошло по цепочке:
- UI не подлежит тестированию в принципе
- а вот в asp.net mvc/HTML/javascript подлежит
- а вы юзайте MVVM и вообще не пишите веб, пишите под сильверлайт

Хотя, судя по обсуждению, один я web-ом занимаюсь, а все остальные спокойно пишут под win. Тогда еще можно понять почему UI считают легким налетом поверх BL.

Это сообщение отредактировал(а) PashaPash - 16.11.2009, 18:00

какая-то непонятная и болезненная реакция на точку зрения, отличную от Вашей, PashaPash, 
Я высказал свои мысли, как и все остальные. Жаль что не они пришлись Вам по душе...


сильверлайт - это web-ориентированная технология, к сведению...


Надеюсь что да.

Вы глубоко заблуждаетесь


я на звание гуру не претендовал. И попрошу Вас, уважаемый, держаться в рамках. Очень бы хотелось...

В остальном - я умолкаю. 
Все что я хотел сказать - я сказал. Как сумел.

tol05, я просто очень болезненно реагирую на фразу "UI тестированию не подлежит". Весь день перед этим убит на прикручивание Selenium к cc.net, исключительно ради тестов на UI.

Возможно, у нас действительно проблемы с архитектурой, и стоит перейти на silverlight, генерацию скриптов и прочее. Ваш совет нанять архитектора - очень полезен, но сначала хотелось бы видеть хоть какую-то надежду. Сейчас у нас генерируемое по метаданным UI, с Silverlight, вполне ровное в архитектурном плане. Но неприемлимое с точки зрения пользователя, по вышеперечисленным причинам. Боюсь, что нанятый архитектор посоветует бороть проблемы со скоростью и временем отклика ... переписыванием логики UI на javascript. Точнее, уже минимум два "архитектора по вызову" так посоветовали. У вас есть контакт "правильного" архитектора, желательно в Минске?


Вы глубоко заблуждаетесь (с) Приведите хоть один агрумент, ссылку на источник. Почему вы промолчали раньше, когда я явно попросил прояснить термин UI в Вашем понимании? Ну или ответьте на вопрос - UI Processing Component - это часть UI?


Гуру употреблен не ради насмешки. Человек с 145 репутации вполне заслуживает звания гуру  Я действительно надеюсь что вы приведете советы по генерации нетривиального UI. Жаль что вы так отреагировали на просьбу помочь в вполне конкретной ситуации. Я не ожидал, что после бодрого начала о "генерации скриптов" и "выноса логики из UI" вы вдруг так странно воспримите вопрос о применении Вашего подхода к вполне реальной и актуальной для меня проблеме. Просьба о применении Ваших знаний (в которых вы меня вполне убедили) - это выход из рамок?

Это сообщение отредактировал(а) PashaPash - 16.11.2009, 21:30

ЗЫ. Если бы я действительно пытался отрицать чужую точку зрения и наезжать на остальных, я бы не писал длинных развернутых ответов. Я бы сделал так:

Бизнес-логика (!) на javascript (!!) в client tier (!!!) в web (!!!!). И этот феерический бред 2 раза плюсанули???
Но ведь не делаю, пытаюсь вежливо отвечать. Сорри, не удержался. No offence к ivashkanet, я прекрасно понял смысл сообщения. Строчка выше - шутка. Но в любом случае - глубокое презрение к плюсовавшим.

Это сообщение отредактировал(а) PashaPash - 16.11.2009, 23:43

Насколько я понял, просто Паша под UI понимает презентейшен-лейер (в том или ином виде), а BL - лейер бизнес-логики. Остальные же: UI - код, ответственный непосредсвенно за UI, BL - код, отвечающий за некоторую внутреннюю (в различных смыслах) логику.

Добавлено через 4 минуты и 32 секунды
Ах да, насчёт яваскрипта:
1. Это оффтопик  
2. Я за ручное написание. Яваскрипт - отличный язык со своими паттернами. Проблема производительности? Ну.. она везде есть  Вопрос времени, ситуации и компромиссов (к каждому со своей стороны)..

Любитель, ну хоть кто-то читает мои мессаги. 
JavaScript - не оффтопик, по крайней мере после анонса coded user interface test в 2010-й студии.
http://blogs.msdn.com/paulcornell/archive/...ui-testing.aspx
Там встречаются слова ui testing и ui layer, но с этим ничего поделать - они не читают винград.

Ну.. на всякий случай - я тоже привык под UI-кодом понимать код, ответственный именно за UI. BL правда противопоставлением не является.. Даже не знаю, обычно просто юай и логика  Уж простите за банальность.

Что касается оффтопик или нет: конкретные метод разработки на JS, конкретные паттерны и пр. - ИМХО оффтопик, тулзы для генерации, тестирования, поддержки и пр., а также организация процесса JS-девелопмента (хотя я бы не стал это так особо выделять) - нет, конечно.

UI код - код ответственный за UI - это нефункциональное определение.
Бизнес-логика — совокупность правил, принципов, зависимостей поведения объектов предметной области системы. Если логика описывает поведение UI - то она не бизнес. 

Неважно, кто и как понимает. Есть вполне строгая терминология, и если ее не придерживаться - то будет бесполезный спор. Когда на любые попытки уточнить терминологию получаешь "вы глубоко заблуждаетесь". 

Есть официальный гайд от MS по архитектуре. Давайте его придерживаться. По гайду - UI - это area of concern - группировка функционала. За нее отвечает Presentation Layer. Все остальные толкования терина UI в пределах топика ничем не подтверждены. а толкователи - глубоко заблуждаются, или намеренно запутывают терминологию, IMHO.

Ну в и целом спор довольно странный 
- MS включило в VS2010 поддержку coded user interface tests
- Телерики выпустили WebUI Test Studio, с поддержкой Silverlight
- TargetProcess пытается покрыть UI тестами (это для фанатов agile аргумент)
- Местные QA пищат от Selenium-а
- На винграде меня убеждают что UI тестированию не подлежит в принципе. И что я глубоко заблуждаюсь. 

Только мне кажется что с последним пунктом что-то не то?

Это сообщение отредактировал(а) PashaPash - 17.11.2009, 03:15

В классическом разделении по лейерам слово UI не фигурирует.
Что касается тестирования UI.. Тестировать UI необходимо. Всё надо тестировать. Тут вопрос в том, мануальное это тестирование или нет. Так вот, сам UI - мануально и никак иначе. Ну как мы нормально увидим, что там блоки разъехались не так?! Взаимодействие UI с остальными частями - вполне себе автоматизируется.

Любитель, блоки разъехались - это не баг в UI, это баг в Page Layout. 

UI - это не layer, если по классике. Это "проблемная область". Его нельзя тестировать, и он не может ни с чем взаимодействовать. И его нельзя "автосгенерить" и "вынести из него скрипты". 
Presentation Layer - это код, полностью посвященный проблемной области "пользовательский итерфейс" в классическом разделении. И в нем внутри бывает много логики.

Мне проще написать "тесты на UI", чем "тесты на код, отвечающий за функционал в пределах UI area of concern". И судя по гуглу, не только мне.