Паша, я не пытаюсь отрицать твою точку зрения. Я ее понимаю и уважаю. Я банально устал с тобой спорить.
Вся беда в том, ИМО, что своими "длинными развернутыми ответоами" ты уводишь от темы. Просмотри нашу дискуссию еще раз. Ты увидишь, что я старался сконцентрироваться на чем-то конкретном, а ты все добавлял и добавлял новые аспекты (или вспоминал старые)


Нда, вот этого я от тебя не ожидал. Дальше я буду писать прописные истины.
Браузерные приложения -- приложения клиент серверные. С сервером все понятно, а вот клиента часто недооценивают. А между прочим на HTML&CSS + JavaScript можно писать не менее Rich приложения, чем на тех же формах. 
Проблема толко в том, что это делать не так удобно как на том же WinForms. Но это проблема не JavaScript, а отсутствия готовых инструментов. Хорошо, что в последнее время это направление стало усиленно развиваться. JQuery, Prototype, Dojo, ExtJS,...
Даже браузерных Осей уже вагон написали. Не говоря о болле простых приложениях.

Но разговор не об этом, а об BL на JavaScript в Client Tier в вэб приложениях.
В моем понимании BL -- это логика, важная для бизнеса, т.е. людей, которые пользуются нашим приложениям.


Сразу скажу, я еще не настоящий сварщик JavaScript програмист и ни разу не писал JavaScript который можно тестировать. Так, стандартные макаронины  Так что дальше будет не про тестируемость BL на скрипте, а про саму BL.

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

Главный момент: JavaScript -- мощный и функционалный язык, вот только язык силен не сам по себе, а всевозможным middleware для этого языка. Чего у JS не густо.

Ээ.. А это не UI?! А если этот лейаут строится так или иначе динамически? Баг вполне может быть в скрипте там каком-нибудь...

Майкрософт всегда ориентировалась на посредственных пользователей (программеры -- пользователи VS). Кроме того это модно.
Следовательно -- это бабки.


См выше.


Опять выше. Если ты производишь Agile инструмент -- не факт что ты сам agile. Agile сейчас такой же бизнес, чем макдональдс и кока кола.


Ну и пусть пищат. Еще бы. Вместо повторения изо дня в день кликов по формам, можно эти клики записать в мастере. 
Но дело в том, что это  ИХ инструмент. Но никак не мой как девелопера. 
Нет, я понимаю, что их мне можно использовать как временные регрешен тесты. 

Мне не нравится UI тесты для разработчика, потому что они хрупкие (скажем так) и  медленные.
Я предпочитаю изолировать тестируемый класс, набор классов и полностью в тесте контролировать воздействие на них.
С UI так не получиться. Для UI, как минимум, нужна база. Заполенная данными. Для QA это хорошо, для девелопера -- нет.

Тесты должны часто запускаться. Медленные тесты запускаются только на CI сервере. 


Заблуждаешься. Тестировать UI можно и нужно. Этим занимается QA. Вот пусть и дальше этим занимается.

Это сообщение отредактировал(а) ivashkanet - 18.11.2009, 11:33

ivashkanet, ну вот, понеслось  Ты не с тем человеком споришь. Сейчас покажу фокус:



Красиво, да? Я могу идти за попкорном?

Я вообще не утверждал что UI должны тестировать разработчики. У нас тесты на UI пишут QA. По крайней мере, пытаются. И крутятся эти тесты на CI сервере. С двумя твоими постами я почти полностью согласен. Упоминание UI тестов как "сначала пишем UI тесты" выше было в контексте "неправильного TDD".

Топик посвящен процессу. Если CI - часть процесса, то тесты на UI - тоже.


Т.е. вообще вся логика приложения... В моем понимании, есть BL - логика доменной области. И UI логика - логика взаимодействия с пользователем. Почти все модные паттерны, типа MVC, это разделение вводят. Ну и опять же, есть гайд со строгим определением, а не моим или твоим пониманием. http://apparch.codeplex.com/. Там куча ссылок на источники, чтобы показать что это не ламерская дока от MS. 
Могу даже процитировать, Presentation Layer ... common issues ... UI Process Components ... Mixing business logic with UI process logic.

EDIT: у нас когда-то один препод в универе любил спрашивать - а что такое бизнес-логика. И в ответ на "важная для бизнеса и для людей" уточнял - "а в приложении есть еще и другая, не важная для бизнеса и для людей, логика"? No joking.


Это часть UI. Ну, "разъехались" очень трудно протестировать. А вот "кнопка не включилась", что чаще случается - очень просто.

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

Что чаще случается - это спорно  

Не спорно, просто it depends  У нас второе чаще. Даже слишком часто. 

Надо было топик назвать "не ищи определение, придумай свое понимание UI/BL/whatever и убеди PashaPash что он в корне не прав". И брать деньги за вход. Я уже вижу следующий виток. Код DataAccess полезен людям и бизнесу, поэтому он - бизнес-логика.

Предлагаю вернуться к теме обсуждения. Где списки инструментов, где процесс от участников?

О, и мне немножко! Если чессно, то я по диагонали читаю этот поток мыслей  Сорри.


Ураааа, взаимопонимание     


Мы ведь говорим про процесс разработки (программерами), а не весь процесс разработки начиная от анализа требований до приемо  сдаточных испытаний и ввода в эксплуатацию. Так?

Тогда спорно.  UI тесты пишутся QA. Ночной билд сломался. Полетели UI тесты. 
Кто по Процессу должен разбираться в причине? Если разработчики, то что делать если UI тест криво написан и не учитывает новых  изменений? Если QA, то почему сломался билд, почему отвлекли разработчиков от этого?
Получается, у QA должен быть свой билд сервер. Во как  


О, вагон. Рюшечки, бантики, фенечки; низкоуровневые детали реализации. Т.е. все то, без чего приложение все еще будет приносить пользу, либо то, что можно кардинально изменить.

В любом случае, какое бы ты (правильное) определение ни привел. Все что я написал выше останется примерами бизнесс логики.

Тоже масло масленное ;-)


Люди много чего написали в мире. Было время я все это читал перечитывал. Сейчас стараюсь стремиться к простоте и руководствоваться здравым смыслом. Ну и держать руку на пульсе. 


Заметь, тему называл ты  

СУВ, ivashkanet

Добавлено через 11 минут и 26 секунд

У Скрама есть отличная практика. Называется Ретроспектива. Это когда в конце спринта люди собираются и обсуждают что хорошего было внесено в Процесс, что не работает, что мы, возможно, не так поняли. В конце выносится решение нужно ли продолжать использовать "это" или нет. Попробовали TDD -- оказалось, что стало есть много времени, кодить некогда. Отказались. Попробовали Специальную тулзу -- отлично работает ...
Вот это грамотно. В общем нужно не стоять на месте, а двигаться. Не важно куда, вперед, назад, влево, вправо. То что работает для одних, не факт будет работать для вас.  Голова на плечах подскажет когда вы движетесь не туда. Зато вы можете найти звою "бронзовоую пульку" 

Но для этого, как и вообще для Agile нужны высокий уровень команды и некоторая степень свободы со стороны менеджера. 
И вообще: Agile -- это сложно!

Это нечестно! Почему меня за тестирование UI послали нанимать архитектора, а тебя - нет :(


Процесса разработки (программерами) IMHO не бывает.

Ну, не совсем. доменная (предметная область) - вполне самостоятельное понятие. Скажем, проекты, задачи, баги, ассайны у нас. Логика которая человека на проект ассайнит - бизнес. А которая галочки на странице снимает и поля отключает - не бизнес. Навигация - тоже не бизнес. 
Ну хоть чуть более точное определение, чем "полезная людям" 


Ну, не совсем 
На практике - валидация - практически единственная бизнес-логика, которая должна вылазить в Presentation в не-rich клиенте. И при том дублироваться на сервере. Даже не логика, а business rules. счас даже цитату воткну:
Avoid business rules, with the exception of input and data validation, in UI processing components.
Layers should represent a logical grouping of components. For example, use separate layers for user interface, business logic, and data access components.
Components within a layer should be cohesive. In other words, the business layer components should provide only operations related to application business logic.

В rich все сложнее, но надо учитывать что rich client - это отдельное приложение, которое почти целиком на client tier работает. Rich client на javascript встречается в вебе очень редко. И все эти UI Test Framework-и - больше для тестирования UI Processing, чем BL.


Да, но надо хоть раз в пару лет перечитывать. Долгими зимними ночами  Тем более что дока там без воды почти.

Кстати, у вас SCRUM? Какой размер команды, что пишете, на чем? 

Добавлено через 13 минут и 32 секунды

Я минут 20 над названием думал.  Даже хотел на темы поделить. Надо дописать - не гербалайф TDD.

ААААА, ну я не знаю как это называется.  Программеры -- программируют. У них собственный процесс. Свои задачи, сферы ответственности и проч. У QA свое. Я где-то как-то про нечто в этом смысле сказать хотел  


Ключевое слово "должна". Вот только зачастую лазить на сервер за небольшими изменениями затратно. Вот и приходим к жаваскрипту.

Не обязательно. Есть подходы которые позволяют использовать общий набор правил. Там правда колбаса с кодогенерацией и посетителем, так что для прикручивание этого нужны хорошие скилы. Но, однажды настроенная, система работает как часы. 


Тупо негде применять. Мои проекты не требуют такой уровень знаний. У меня и так overskill раза в два: то что я предлагаю либо никто не понимает и полностью сваливают реализацию на меня, либо говорят нинуно это нам, бум клобасить по старинке (город небольшой, всего 3 программерских конторы и все быдлокодят в аутсорсе).

Я сейчас Ruby и ее рельсы осваиваю. Суперский язык. Стремает немного динамическая типизация. Но сколько возможностей дает этот подход   


Да ты что, окстись. У нашего чудо процесса даже названия, думаю, нет. Так, потиху кодим. И если что-то вводим, то втихаря от менеджера. Вот так вот.

Ес-но, я имел ввиду что код будет дублироваться (точнее, должен). Ради этого в 3.5 SP1 (или бете 4-ки, не помню) во фреймворк затянули кучу аттрибутов. Кстати, насчет глобальной кодогенерации - http://thedailywtf.com/Articles/The_Custom...dly_System.aspx. 


И ты, Брут...

Угу! 
Нужно расти вширь. Вглубь без практики понту нет  


Ты о кодконтрактах? Их цель в другом.. Хотя они отлично расширяютя для генерации скриптов валидации.


Любая крайность плоха.

Есть еще System.ComponentModel.DataAnnotations. Они для DynamicData введены, но вполне можно и в других целях использовать. Для asp.net mvc, например, есть готовый model binder, который их понимает: http://www.asp.net/learn/mvc/tutorial-39-cs.aspx

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

Нашел перевод зачетной статьи про ТДД. 
Очень грамотно написано и очень мне близко так как перекликается с тем, к чему пришел я.

вот золотые слова )))