Здравствуйте, Aviator, Вы писали:
A>И опять ты ничего не понял. Я говорил про юнит тесты, а приведённый пример показывает необходимость функционального тестирования. Оно действительно необходимо, но сначала небольшие куски кода проверяются с помощью юнит тестов. Юнит тесты проверяют соответсвие ожидаемого поведения классов и методов с фактическим. Функциональное тестирование проверяет соответсвие предоставляемой приложением функциональности требованиям ТЗ. Это две разные разницы и совершенно различные сферы ответственности. Даже люди вовлечены разные.
Да нет это ты не понял. Разница в том, что люди вовслечены. Для перечисленных задач требует ручное тестирование. Можно и ручное юнит-тестрирование устроить, принципиальной проблемы нет. Важно тут то, что автоматизировать этот процесс не представляется возможным.
Здравствуйте, kuj, Вы писали:
kuj>Мда... я не завидую вашим разработчикам БД, но еще больше я не завидую вашим разработчикам BLL...
adontz прав, приложение должно разрабатываться по информационной структуре, а не информационная структура по приложению. Вы должны прекрасно понимать, что приложение лишь интерфейс для управления информацией.
Re[15]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, adontz, Вы писали:
C>>Ты знаешь, если мне это нужно будет — я точно так же сделаю два класса User и UserDetails. А если у нас только два поля FirstName/LastName — пусть себе живут в одной таблице.
A>Это надо делать не когда нужно, а на всякий случай. Именно это и отличает хорошего специальста, что он разрабатывает продукт не только для сегодняшнего дня, а с учётом возможных расширений.
Таким образом можно насоздавать только монстриков, в которых напихано всего на всякий случай, а то что нужно они делать не умеют.
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, IT, Вы писали:
A>>Это надо делать не когда нужно, а на всякий случай. Именно это и отличает хорошего специальста, что он разрабатывает продукт не только для сегодняшнего дня, а с учётом возможных расширений.
IT>Таким образом можно насоздавать только монстриков, в которых напихано всего на всякий случай, а то что нужно они делать не умеют.
Я имел ввиду не добавлять функциональность, а оставлять возможность безболезненного добавления функциональности.
kuj>>Мда... я не завидую вашим разработчикам БД, но еще больше я не завидую вашим разработчикам BLL...
С>adontz прав, приложение должно разрабатываться по информационной структуре,
С чего Вы взяли, что БД это информационная структура приложения? БД это самый нижний уровень для хранения информации. Вот и все и нечего тут выдумывать.
С>Вы должны прекрасно понимать, что приложение лишь интерфейс для управления информацией.
Это не так. Приложение это интерфейс для решения конкретных бизнес-задач, а не для управления информацией. Понятие информация вообще на столько абстрактное, что не понятно к чему Вы его приплели.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[23]: Оформление работы с БД в корпоративных приложениях -
kuj>>Где там явный вызов функции и чем это отличается от CREATE TABLE?
A>Явный вызов там MessageBox.__ctor.
Точно так же, как и CREATE TABLE явно императивный оператор означающий: создай мне таблицу с такой-то структурой. Точно так же как и MyObject.CreateAnotherObject(AnotherObjectParams p);
Разница только в синтаксисе.
A>От CreateTable это отличается тем, что ты декларируешь результат — таблицу, но не знаешь как она будет создана, каки функции будут вызваны и будут ли вызваны вообще.
А Вы знаете какие функции будут вызваны в конструкторе MessageBox? Честно-честно?
Короче, Вы НЕ знаете что такое декларативное программирование. Если Вы считаете CREATE TABLE декларативным программированием, то вопросов больше нет. Пробелы в Вашем образовании я восполнять не собираюсь.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[20]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, adontz, Вы писали:
A>Да нет это ты не понял. Разница в том, что люди вовслечены. Для перечисленных задач требует ручное тестирование. Можно и ручное юнит-тестрирование устроить, принципиальной проблемы нет. Важно тут то, что автоматизировать этот процесс не представляется возможным.
В юмор однозначно. Про "ручное юнит тестирование" это твоё изобретение?
Re[24]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, kuj, Вы писали:
kuj>А Вы знаете какие функции будут вызваны в конструкторе MessageBox? Честно-честно?
Как минимум будет вызван сам конструктор.
Здравствуйте, adontz, Вы писали:
kuj>>То есть ХП уже не тестируемые вовсе? Как полярно у Вас поменялось мнение... Надо же.
A>То есть научись читать по-русски. Для тебя предложенияе с двумя запятыми уже проблема.
Вы сперва определитесь можно ли тестировать ХП или нет. "Не не полностью" это не русский язык. Это называется двойное отрицание.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[21]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, Aviator, Вы писали:
A>>Да нет это ты не понял. Разница в том, что люди вовслечены. Для перечисленных задач требует ручное тестирование. Можно и ручное юнит-тестрирование устроить, принципиальной проблемы нет. Важно тут то, что автоматизировать этот процесс не представляется возможным.
A>В юмор однозначно. Про "ручное юнит тестирование" это твоё изобретение?
А почему бы и нет? Например можно прослушивать все расространённые слоги оценивая качество синтезации речи, прежде чем переходить к фразам. Ты вообще увидел сейчас что-то незнакомое и выдал какое-то истеричное "ха-ха". Да, бывает и ручное юнит-тестирование если критерий корректности нельзя проверить автоматически. Вообще напиши что-то сложнее склада, потом и поговорим.
Здравствуйте, adontz, Вы писали:
A>>нифига ты не тестируешь логику. А все тесты наверняка сводятся к проигрыванию пары сценариев на подготовленной базе
A>Сценариев не пара. Логика тестируется. Телепатию в сад.
Ну так расскажите нам КАК Вы тестируете логику? Мы не телепаты — понять Вас без слов не можем.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[5]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, Aviator, Вы писали:
A>Вы ошибаетемсь, большинство знаний подчерпывается из литературы, примеров в инете, опен сурс проектов и форумов. Далеко не у каждого есть возможность поучиться у коллег .
A>>Не тестируемые это как? Объяснение с примером в стулию. У вас что, поведение кода непредсказуемое? Ну тогда тут вообще нечего обсуждать .
A>Не тестируемые, значит что ты НЕ можешь автоматически проверить корректность кода.
Если Вы не можете проверить корректность кода, значит Вы просто неправильно этот код написали. Вот и все.
A>Код, который с помошью OpenGL визуализирует карту страны и траекторию движения автомобилей на ней. Ты должен просто сесть и помотреть "то" на экране нарисовано или "не то".
Ндааааааа.... Это сильно...
A>Как ты в юнит-тесте проверишь благозвучность синтезированной речи?
Кто Вам сказал, что юнит-тесты должны проверять благозвучность речи? Вы так и не разобрались что такое юнит-тесты... Это как в анекдоте про чукчу-писателя.
A>Нельзя проверить, что HTML правильно отображается на экране, надо просто открыть и посмотреть.
5 баллов...
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[22]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, kuj, Вы писали:
kuj>Ну так расскажите нам КАК Вы тестируете логику? Мы не телепаты — понять Вас без слов не можем.
Создаётся некоторая предопределённая база (схема+данные). Натравляется ХП. Проверяется, что данные после исполнения ХП соответствуют ожидаемым. Я не думал, что такие вещи надо объяснять.
A>>И опять ты ничего не понял. Я говорил про юнит тесты, а приведённый пример показывает необходимость функционального тестирования. Оно действительно необходимо, но сначала небольшие куски кода проверяются с помощью юнит тестов. Юнит тесты проверяют соответсвие ожидаемого поведения классов и методов с фактическим. Функциональное тестирование проверяет соответсвие предоставляемой приложением функциональности требованиям ТЗ. Это две разные разницы и совершенно различные сферы ответственности. Даже люди вовлечены разные.
A>Да нет это ты не понял. Разница в том, что люди вовслечены. Для перечисленных задач требует ручное тестирование. Можно и ручное юнит-тестрирование устроить, принципиальной проблемы нет. Важно тут то, что автоматизировать этот процесс не представляется возможным.
Ручное юнит тестирование. Ей Богу, не поленюсь, соберу все Ваши перлы из этого топика распечатаю и повешу на стену в офисе. Будет народу с утра настроение поднимать.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[19]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, kuj, Вы писали:
A>>Не тестируемые, значит что ты НЕ можешь автоматически проверить корректность кода. kuj>Если Вы не можете проверить корректность кода
Могу. Не могу сделать это автоматически. кроме того понятие корректности может быть не детерминированным. Благозвуность речи не тот пораметр, который можно свети к Да/Нет.
A>>Код, который с помошью OpenGL визуализирует карту страны и траекторию движения автомобилей на ней. Ты должен просто сесть и помотреть "то" на экране нарисовано или "не то". kuj>Ндааааааа.... Это сильно...
Ещё бы, ты ведь дальше своего носа ничего не видел, всё новое тебя удивляет.
kuj>Кто Вам сказал, что юнит-тесты должны проверять благозвучность речи?
А где я тут сказал юнит-тесты? Я тут о тестрировании вообще. Ты как всегда что-то не в тему ляпнул.
Здравствуйте, adontz, Вы писали:
kuj>>Все верно. Потому я и считаю, что в случае корпоративных приложений БД следует использовать исключительно как хранилище информации — без хранимых процедур и триггеров.
A>Вот это и называется фанатично верить в технологию.
Это называется знать реалии жизни.
A>Есть КУЧА задач, где юнит-тестирование в частности и тестирование вообще не возможно и разглядывание кода (если повезёт, логов) единственный метод отладки. И несмотря ни на что эти задачи успешно решаются.
Нету никакой кучи задач. Юнит-тесты это не что-то из ряда фантастики, а вполне конкретная методология автоматического тестирования кода, которой вот уже много-много лет. Вы о ней НИЧЕГО не знаете, но продолжаете спорить, выставляя себя дураком.
Разберитесь сначала, изучите, а потом спорьте.
kuj>>В том то и дело, что прогон раз в сутки часто не достаточно. В идеале тесты должны прогоняться после малейшего изменения. Потому и необходимо столь жесткое разделение на слои и домены: хранилище — DAL — BLL — ...
A>Идеалист-маньяк Тест после каждого коммита в крупном проекте требует огромной по вычислительной мощности инфраструктуры компиляции и тестрирования.
Ну так идете и разберитесь с юнит-тестированием, а так же с прицнипами DDD.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[20]: Оформление работы с БД в корпоративных приложениях -
A>>>Не тестируемые, значит что ты НЕ можешь автоматически проверить корректность кода. kuj>>Если Вы не можете проверить корректность кода
A>Могу. Не могу сделать это автоматически. кроме того понятие корректности может быть не детерминированным. Благозвуность речи не тот пораметр, который можно свети к Да/Нет.
Есть вполне конкретные алгоритмы синтезирования с вполне конкретными детерменированными состояниями. Благозвучность речи, удобство и юзабилити интерфейса пользователя и т.д. — это все проверяется людьми-тестерами.
И вообще какое это все имеет отношение к корпоративным приложениям? Мы говорим о невозможности тестирования ХП в отличии от тестирования CLR-эквивалента.
A>>>Код, который с помошью OpenGL визуализирует карту страны и траекторию движения автомобилей на ней. Ты должен просто сесть и помотреть "то" на экране нарисовано или "не то". kuj>>Ндааааааа.... Это сильно...
A>Ещё бы, ты ведь дальше своего носа ничего не видел, всё новое тебя удивляет.
Сильно то, что Вы не понимаете ни разу что такое юнит-тестирование.
kuj>>Кто Вам сказал, что юнит-тесты должны проверять благозвучность речи?
A>А где я тут сказал юнит-тесты? Я тут о тестрировании вообще. Ты как всегда что-то не в тему ляпнул.
Вот те раз приехали! Мы ему об автоматическом тестировании кода с помощью юнит-тестов, а он нам ахинею про "тестирование вообще".
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[14]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, kuj, Вы писали:
A>>Есть КУЧА задач, где юнит-тестирование в частности и тестирование вообще не возможно и разглядывание кода (если повезёт, логов) единственный метод отладки. И несмотря ни на что эти задачи успешно решаются. kuj>Нету никакой кучи задач.
Например, синхронизация многопоточных приложений не поддаётся тестированию. Учи матчасть.
Если нам не помогут, то мы тоже никого не пощадим.
Издательство: 
Издательство: Питер
Издательство: 
Издательство: Русская Редакция
