Здравствуйте, Vladek, Вы писали:
V>Ага, тестировать надо только публичный API.
Я ведь не Микрософт — у меня нет "кастомеров" моего API, кроме меня (или моей команды). Я не продаю свою либу. Что в этом случае значит публичный API? Просто public методы? Дык я их создавал не для каких-то абстрактных разработчиков, а конкретно для своего проекта.
HL>> Другое дело — это "бузинесс"-"методы" GetCustomerById, который состоит из вызова "select * from Customer where CustomerID = @id", в котором тестировать НЕЧЕГО. Ну т.е. конечно можно протестировать что он возвращает кастомеров с ID=3, ID=1, поддерживает отрицательные ID, в результате есть такие-то колонки итд. Но усилий по написанию и, главное, поддержке вы потратите гораздо больше, чем если просто откроете site.com/Customers/1 и убедитесь, что оно не валится. Ну или заскиптуете каким-нить веб-кликером за 5 секунд. Или просто Вася зайдёт на страничку и убедится, что не валится.
V>Из презентации: V>
Test only that API exposes.
См. выше.
V>В GetCustomerById, если это часть public API, тестируется маппинг объектов. Доступ к БД мокируется. Если такой тест трудно написать, значит в этом методе проблемы и само намерение написать тест уже показало это.
В том-то и дело, что в реальных ERP-системах запросы чрезвычайно сложны. И если при тестировании Hello World мы огребаем по полной, то нафига нам вообще весь этот гемор с маперами, моками, тестами? Всё равно почти весь код сидит в БД, завязан на БД и жить не может без БД. Реализация же всего на C# только для целей тестирования — это, во-первых, безумно неэффективно с точки зрения производительности (база всё равно будет быстрее в ERP),а, во-вторых, это усложняет архитектуру систему в буквально десятки раз.
V>Если приходится тестировать закрытый метод, то это в 99% случаев значит что этот метод должен быть открытым в другом классе.
HL>>Короче, Шура, пишите, пишите тесты. Только потом не возмущайтесь, добавление колонки в базу стало СВЕРХ-СЛОЖНЫМ ИНЖЕНЕРНЫМ ПРОЕКТОМ. V>Ну я говорю, с маппингом проблемы.
Проблема не в маппинге, конечно. Проблема в API. Если API — это black box, unit-тестирование рулит, если это примитивные методы типа GetCustomerByID или супер-навороченные запросы, вы можете просто убиться для того, чтобы их протестировать. И даже в этом случае в этом не будет смысла.
Здравствуйте, iHateLogins, Вы писали:
HL>Здравствуйте, Vladek, Вы писали:
V>>Ага, тестировать надо только публичный API.
HL>Я ведь не Микрософт — у меня нет "кастомеров" моего API, кроме меня (или моей команды). Я не продаю свою либу. Что в этом случае значит публичный API? Просто public методы? Дык я их создавал не для каких-то абстрактных разработчиков, а конкретно для своего проекта.
А как одна подсистема общается с другой? Я вот могу выделить пять подсистем в бизнес-приложении: Presentation (пользовательский интерфейс), Application (бизнес-логика), Infrastructure (бизнес-правила), Configuration (конфигурация, определяет какие бизнес-правила будут действовать), DataAccess (бизнес-объекты, маппинг) и DataSource (хранение данных) часто объединены. Все они общаются друг с другом посредством API, который надо проектировать и лучше делать это осознанно, с использованием тестов.
V>>В GetCustomerById, если это часть public API, тестируется маппинг объектов. Доступ к БД мокируется. Если такой тест трудно написать, значит в этом методе проблемы и само намерение написать тест уже показало это.
HL>В том-то и дело, что в реальных ERP-системах запросы чрезвычайно сложны. И если при тестировании Hello World мы огребаем по полной, то нафига нам вообще весь этот гемор с маперами, моками, тестами? Всё равно почти весь код сидит в БД, завязан на БД и жить не может без БД. Реализация же всего на C# только для целей тестирования — это, во-первых, безумно неэффективно с точки зрения производительности (база всё равно будет быстрее в ERP),а, во-вторых, это усложняет архитектуру систему в буквально десятки раз.
HL>Проблема не в маппинге, конечно. Проблема в API. Если API — это black box, unit-тестирование рулит, если это примитивные методы типа GetCustomerByID или супер-навороченные запросы, вы можете просто убиться для того, чтобы их протестировать. И даже в этом случае в этом не будет смысла.
Если писать приложения в стиле "сдал и забыл", то наверное. Последние четыре проекта, в которых я участвовал, были полным переделыванием такого творчества с нуля.
Здравствуйте, landerhigh, Вы писали:
L>Потому что тема больно общая.
L>Вчера наткнулся на это (вроде не баян). ППКС, так как я сам test infected. Программистам смотреть обязательно, вне зависимости от языка и платформы.
Не осилил постоянно жать на кнопку, чтобы увидеть очередную "мудрость". Это для людей с дислексией сделано — не больше 10 символов одновременно на экране? ))
Какой-то бездельничающий графоман склепал презентацию с претензией на нужность и полезность. И с потугами на "юмор". На мой взгляд, мусор полнейший.
Здравствуйте, landerhigh, Вы писали:
L>Потому что тема больно общая.
L>Вчера наткнулся на это (вроде не баян). ППКС, так как я сам test infected. Программистам смотреть обязательно, вне зависимости от языка и платформы.
L>Вчера наткнулся на это (вроде не баян). ППКС, так как я сам test infected. Программистам смотреть обязательно, вне зависимости от языка и платформы.
Тесты — дело хорошее, но. Сроки и бюджеты для нехайтек проектов порой берутся с потолка. Поэтому работают все в спешке. Получается дилема: (система с тестами, но недоделанная ИЛИ система без тестов, но имеющая всю функциональность, кое как протестированную). Очевидно, всегда годится второй вариант. Если это состояние достигнуто, можно систему впарить и исправить баги уже за доп. деньги.
Клёво, конечно, работать в каком-нибудь гугле, который может себе позволить выпускать качественные продукты. Но в reallife продукты некачественные.
Удвой число ошибок, если не получается добиться цели.
Здравствуйте, Vladek, Вы писали:
V>>>Ага, тестировать надо только публичный API.
HL>>Я ведь не Микрософт — у меня нет "кастомеров" моего API, кроме меня (или моей команды). Я не продаю свою либу. Что в этом случае значит публичный API? Просто public методы? Дык я их создавал не для каких-то абстрактных разработчиков, а конкретно для своего проекта.
V>А как одна подсистема общается с другой? Я вот могу выделить пять подсистем в бизнес-приложении: Presentation (пользовательский интерфейс), Application (бизнес-логика), Infrastructure (бизнес-правила), Configuration (конфигурация, определяет какие бизнес-правила будут действовать), DataAccess (бизнес-объекты, маппинг) и DataSource (хранение данных) часто объединены. Все они общаются друг с другом посредством API, который надо проектировать и лучше делать это осознанно, с использованием тестов.
Я не знаю, что за прикладу ты писал, но подозреваю, что ты малость переусложнил. Подозреваю, что добавление просто новой сущности в БД у тебя приведёт к написанию ДЕСЯТКОВ, если не СОТЕН всяких разнообразных классов. Бедные заказчики, которым под соусом "правильной" разработки подсунули фигню, которую, чтобы "правильно" поддерживать, надо писать ТОННЫ всякого plumbing кода.
V>>>В GetCustomerById, если это часть public API, тестируется маппинг объектов. Доступ к БД мокируется. Если такой тест трудно написать, значит в этом методе проблемы и само намерение написать тест уже показало это.
HL>>В том-то и дело, что в реальных ERP-системах запросы чрезвычайно сложны. И если при тестировании Hello World мы огребаем по полной, то нафига нам вообще весь этот гемор с маперами, моками, тестами? Всё равно почти весь код сидит в БД, завязан на БД и жить не может без БД. Реализация же всего на C# только для целей тестирования — это, во-первых, безумно неэффективно с точки зрения производительности (база всё равно будет быстрее в ERP),а, во-вторых, это усложняет архитектуру систему в буквально десятки раз.
HL>>Проблема не в маппинге, конечно. Проблема в API. Если API — это black box, unit-тестирование рулит, если это примитивные методы типа GetCustomerByID или супер-навороченные запросы, вы можете просто убиться для того, чтобы их протестировать. И даже в этом случае в этом не будет смысла.
V>Если писать приложения в стиле "сдал и забыл", то наверное. Последние четыре проекта, в которых я участвовал, были полным переделыванием такого творчества с нуля.
В том-то и дело, что проще всего поддерживаются приложения, которые ПРОЩЕ написаны! Не те, у которых есть 150 уровней абстракции, фабрики фабрик и которые расстрелены при помощи IoC, а которые сделаны ПРОСТО. Такие поддерживать — просто одно удовольствие.
Минус за то, что забыли покрыть юнит-тестами открывание ссылки в разных браузерах.
Ни IE7, ни Safari4 не смогли открыть эту ботву — там mime-тип не указан, а xml по-человечески не рендерится.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, Anton Batenev, Вы писали:
AB>>Эм. А ссылка правильная? А то у меня вот это :\ L>Правильная. Попробуй в лисе.
Нету лисы, вырвал с корнями из системы.
Есть в более фф-независимом формате?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Кодт, Вы писали:
К>Ни IE7, ни Safari4 не смогли открыть эту ботву — там mime-тип не указан, а xml по-человечески не рендерится.
Это, мопед не мой.
Похоже, это какой-то доморощеный транслятор ppt->html
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, Кодт, Вы писали:
К>>Ни IE7, ни Safari4 не смогли открыть эту ботву — там mime-тип не указан, а xml по-человечески не рендерится. L>Это, мопед не мой. L>Похоже, это какой-то доморощеный транслятор ppt->html
Ей-богу, лучше бы выложили ppt.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, iHateLogins, Вы писали:
HL>Также бесполезно спорить с людьми, которые вместо того, чтобы копать (заметьте — не решать дифуры, не искать нефть, а именно копать) начинают "тестировать лопату" каждые 15 минут, проверять схемы экскаватора, цементируют яму бетоном (для надёжности), хотя знают, что завтра бетон придётся вытаскивать обратно.
Вы не знаете, что такое Юнит-тесты, для чего они нужны и как ими правильно пользоваться. Это случается, когда тестирование на проекте внедряется указанием сверху. HL>вместо простых селектов в базе накручиваются просто МЕГАТОННЫ всякого водопроводного (plumbing) говно-кода, фреймворки над фреймворками... а дальше начинается... добавить колонку? СЛОЖНЕЙШАЯ ЗАДАЧА! Переработать модуль? Да проще новый написать, желательно даже не модуль, а проект с нуля, потому что разобраться в тоннах запутанного кода с десятками тысяч никому не нужных юнит-тестов становится просто невозможно.
Замечательно. Отличный пример разработки класса "надо копать".
Возражения по существу будут?
Здравствуйте, landerhigh, Вы писали:
L>Потому что тема больно общая.
L>Вчера наткнулся на это (вроде не баян). ППКС, так как я сам test infected. Программистам смотреть обязательно, вне зависимости от языка и платформы.
По нажатию на указанную ссылку скачался файл index.xul. И чито?
Здравствуйте, iHateLogins, Вы писали:
HL>Видно, что презу писал какой-то дебиловатый скрум-мастер или тренер, который сам код не трогал и не писал и не представляет себе, что применимость юнит-тестов сильно зависит от предметной области.
Применимость тестов вообще не зависит от предметной области. Сушествует очень мало, исчезающе мало случаев, где юнит-тесты, к сожалению, не применимы, но ERP-барахло к ним не относится. Туда в основном относится legacy код вроде драйверов очень низкого уровня, и то только та часть, которая непосредственно общается с железом. HL>Одно дело — реализация спеки какого-то стандарта, которая (реализация) будет черным ящиком. Пример — парсер XML, XSLT, регекспов. Реализаций куча — спека одна. Другое дело — это "бузинесс"-"методы" GetCustomerById, который состоит из вызова "select * from Customer where CustomerID = @id", в котором тестировать НЕЧЕГО. Ну т.е. конечно можно протестировать что он возвращает кастомеров с ID=3, ID=1, поддерживает отрицательные ID, в результате есть такие-то колонки итд. Но усилий по написанию и, главное, поддержке вы потратите гораздо больше, чем если просто откроете site.com/Customers/1 и убедитесь, что оно не валится. Ну или заскиптуете каким-нить веб-кликером за 5 секунд. Или просто Вася зайдёт на страничку и убедится, что не валится.
Ваш код не валится? Можете это доказать? А если на вход мусор подсунуть? Можете это доказать? А вспомните, что нужно вручную протестировать месяца через 2, когда GetCustomerId начнет выковыривать данные из другой таблицы? Точно уверены, что ничего другого не свалится?
Кстати, для веб-программирования тоже существуют тест-фреймворки.
HL>Короче, Шура, пишите, пишите тесты. Только потом не возмущайтесь, добавление колонки в базу стало СВЕРХ-СЛОЖНЫМ ИНЖЕНЕРНЫМ ПРОЕКТОМ.
Вы лично принимали участие в таких проектах?
Здравствуйте, landerhigh, Вы писали:
L>Потому что тема больно общая.
L>Вчера наткнулся на это (вроде не баян). ППКС, так как я сам test infected. Программистам смотреть обязательно, вне зависимости от языка и платформы.
Презентация замечательная, хоть и предназначена только для FireFox, а ведь некоторые "не смотрят FireFox уже три года".
Здравствуйте, AndrewVK, Вы писали:
AVK>А что там? ФФ нет и ставить никакого желания тоже.
Презентация. Юнит-тесты — это круто. Тестировать — это круто. Оттестируй и спи как ребенок.
Очень крупный шрифт, наверное, рассчитывалось на людей с нарушением зрения, странные картинки, некоторые предложения разделены на несколько слайдов — скорее всего, для того, чтобы вся аудитория могла читать хором, по слогам.
Под конец правда презентация сломалась — видимо, недостаточно хорошо тестировали.
Перекуём баги на фичи!
