Вопрос можно? Тестировали вы третий случай в ситуации использования Microsoft ISA Server? У меня почему-то в этом случае он показал свою полную неработоспособность и даже падение в ошибку при HttpContext.Current.Request.Headers[«Accept-Encoding»] (Request был пуст).
Не понимаю что может быть сложного в speed-dial. В данное время есть два направления: задаем сами и браузер решает за нас. Оба направления ущербные. Так надо просто их объединить! Часть пользователь забивает сам (или прикрепляет предложенные), часть постоянно обновляется исходя из открываемых страниц (только давайте уж не предлагать длинные url'ы — предлагайте корень, пусть уж пользователь сам решает — нужны ли ему в спид-диал КОНКРЕТНЫЙ урл, а не сам сайт). И всё. Всякая шняга — сколько их, как расположены — это уже частности.
Ну вот и как ты будешь «данные_такие_то» проверять? Хоть в DataTable тебе их выдай хоть в чём.
«Все данные проверять не надо» — а как же идея-фикс про 100% покрытие кода тестами? А ВДРУГ мы-то и не догадываемся что тут основное?
В базу писать ничего не надо? А вдруг неправильно запросы написали? Что делать? Неужели руками каждый раз перетестировать?
Короче — что же все-таки дает-то такое тестирование? Тут не тестируй, тут упрости, тут вообще заглушки используй…
То есть тестирование UI слишком сложно — пропускаем… Получается что от TDD плясать уже не получается, как это красиво описано в куче статей, о том как от тестов пишем код…
А от тестовых данных в БД плясать… Ну не знаю. Это получается пиши данные — считывай и проверяй читая все строки и сравнивая все ячейки? Так что ли?
В каких проектах вообще применим TDD? Со сложной логикой? Без сложного UI? Без работы с внешними интерфейсами, включая БД? Потому что иначе размер тестов явно превысит сам код раз в 10.
Это даже взять простейший пример, когда тест пишется для функции имеющий 1 вход, 1 выход: требуется проверить и NULL и "" и маленькую строку и большую и ОЧЕНЬ большую и т.д. А берем пример с запросом к базе данных — а там уже с точки зрения выходных данных пусть даже всего 20 полей и 5 разных комбинаций строк — уже имеем дофига вариантов которые НАДО по логике TDD проверять — а ху-ху не хо-хо — пупок-то не развяжется проверять всякую маловероятную ерунду? Когда же сам код-то писать? Элементарный фильтр из 3 частей в каждой 3 чекбокса уже задолбаешься описывать тестами, да еще и само сравнение с возвращаемыми данными из БД…
А Ajax? А JavaScript с точки зрения того же UI? Боюсь даже представить тест сложносвязанной формы и сколько для этого придется кода писать…
По-моему, надо тщательнее проектировать и аккуратно писать код.
Вот читаю, читаю я статьи на Хабре про TDD и BDD и никак вкурить не могу… Примеры приводятся достаточно элементарные, а вот что-то реально нужного никак не могу прочитать.
Давайте рассмотрим банальный подход по принципу BLL->DAL->DB. Предположим у нас GridView отображает данные возвращаемые одним из методов одного из классов неймспейса BLL. Каким образом писать эти тесты для элементарного получения DataTable из базы и тем что должно получится? Писать сравнение каждой строчки возвращаемой? Или мы интерфейс не тестируем? А что мы тогда тестируем? А как тестировать вставку данных? Опять же для проверки формы из 10 полей (пусть все обязательные) какого же размера тест надо написать для разнообразных комбинаций?
Ну, во-первых, это теперь отдельное приложение со всеми своими тараканами. Запускаться автоматически со стартом Opera не умеет (только если в автозапуск ставить, что неудобно, мне нравилось, когда они при старте Opera запускались). Во-вторых, надо каждый раз настраивать режим отображения, почему-то не сохраняет настройку что должно отображаться на рабочем столе. И ещё они после выхода из Opera не закрываются. И вообще у них нет никаких настроек привязки к браузеру (хотя бы открытия/закрытия). Чем теперь это отличается от обычного приложения — вообще не понятно…
А можно вопрос задать не по теме: а зачем все-таки виджеты так испоганили, что они теперь в систему ставятся, а не в Opera? Убили таким образом даже те, которые я использовал… Почему нельзя было и так и так оставить?
Однако, оказывается отсутствие на работе интернета на рабочем месте всё-таки повышает производительность труда — даже если заняться нечем — всё равно берешь и чем-нибудь занимаешься, потому что иначе — скучно!
Обладатели Samsung'ов матерят производителя за поддержку в российских телевизорах всего 5-6 виджетов. И безумно долгой русификации прошивок (вот в октябре обновился на апрельскую, например). Сколько я ещё буду ждать когда у меня в ТВ заработает их пресловутый портал SamsungApps — одному неизвестному корейскому дяде известно…
«Люди не готовы к технологической революции, которая должна произойти»
Понятно. Людишки их уже не устраивают. Ну могу посоветовать свалить подальше, в другую галактику, например, и поискать там более готовых инопланетян.
«Все данные проверять не надо» — а как же идея-фикс про 100% покрытие кода тестами? А ВДРУГ мы-то и не догадываемся что тут основное?
В базу писать ничего не надо? А вдруг неправильно запросы написали? Что делать? Неужели руками каждый раз перетестировать?
Короче — что же все-таки дает-то такое тестирование? Тут не тестируй, тут упрости, тут вообще заглушки используй…
А от тестовых данных в БД плясать… Ну не знаю. Это получается пиши данные — считывай и проверяй читая все строки и сравнивая все ячейки? Так что ли?
В каких проектах вообще применим TDD? Со сложной логикой? Без сложного UI? Без работы с внешними интерфейсами, включая БД? Потому что иначе размер тестов явно превысит сам код раз в 10.
Это даже взять простейший пример, когда тест пишется для функции имеющий 1 вход, 1 выход: требуется проверить и NULL и "" и маленькую строку и большую и ОЧЕНЬ большую и т.д. А берем пример с запросом к базе данных — а там уже с точки зрения выходных данных пусть даже всего 20 полей и 5 разных комбинаций строк — уже имеем дофига вариантов которые НАДО по логике TDD проверять — а ху-ху не хо-хо — пупок-то не развяжется проверять всякую маловероятную ерунду? Когда же сам код-то писать? Элементарный фильтр из 3 частей в каждой 3 чекбокса уже задолбаешься описывать тестами, да еще и само сравнение с возвращаемыми данными из БД…
А Ajax? А JavaScript с точки зрения того же UI? Боюсь даже представить тест сложносвязанной формы и сколько для этого придется кода писать…
По-моему, надо тщательнее проектировать и аккуратно писать код.
Давайте рассмотрим банальный подход по принципу BLL->DAL->DB. Предположим у нас GridView отображает данные возвращаемые одним из методов одного из классов неймспейса BLL. Каким образом писать эти тесты для элементарного получения DataTable из базы и тем что должно получится? Писать сравнение каждой строчки возвращаемой? Или мы интерфейс не тестируем? А что мы тогда тестируем? А как тестировать вставку данных? Опять же для проверки формы из 10 полей (пусть все обязательные) какого же размера тест надо написать для разнообразных комбинаций?
Понятно. Людишки их уже не устраивают. Ну могу посоветовать свалить подальше, в другую галактику, например, и поискать там более готовых инопланетян.