Здравствуйте, Ikemefula, Вы писали:


V>>Ты уже заблудился. В приведенном тобой примере ты тестируешь PreAndPostDoerDecorator, т.е. вот этот код:

I>Конечно. Его и надо тестировать, а не ThirdParty. Это называется поведенческое тестирование

А мужики-то не в курсе.

Ты пока проверил сам факт вызова методов целевого класса. Вместо целевого класса была заглушка. Мои поздравления, это было впечатляюще! Тестирования целевого класса не будет? Коль методы находятся в наследнике, они не пусты, что-то делают. Где тестовое покрытие этих методов? А базовый класс заведомо надежен?


V>>Ты напиши изолированный тест для PreAndPostDecorator, который, например, нетривиально пользует базовый ThirdPartyClass. Вот что представляет интерес для тестирования.

I>Точно такой же подход.

Дык, покажи.

Здравствуйте, samius, Вы писали:

I>>_currentState.Method();

I>>меняется на

I>>СurrentState().Method();

I>>Все. Больше никаких изменений не нужно, ну и currentState выкинуть.

S>Оригинальная трактовка неизменяемости

Здесь нет ничего оригинального. Просто не нужно ГоФ понимать буквально.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>_currentState.Method();

I>>>меняется на

I>>>СurrentState().Method();

I>>>Все. Больше никаких изменений не нужно, ну и currentState выкинуть.

S>>Оригинальная трактовка неизменяемости

I>Здесь нет ничего оригинального. Просто не нужно ГоФ понимать буквально.

Гоф тут не причем. Если объект изменил внешнее поведение, значит он не может считаться неизменяемым, вне зависимости от того, хранится ли состояние в нем самом, или еще где.

Здравствуйте, vdimas, Вы писали:

I>>Никакой. Тебе просто хочется поиграть в какую то свою задачу.

V>Способ изолирования тестирования через заглушки живет вне "каких-то своих" задач.

А выбирается исходя из конкретной задачи. Что бы задетектить вызов двух методов не надо городить ни интерфейсы, ни подменять сборки.

I>>Что бы распознать вызов PreDo и PostDo не нужен ни лишний класс, как у тебя, ни ушлые техники тестирования вроде подмены сборки.

V>Дык, ты упомянул всего один класс, и тот лишь адаптер, не содержащий целевого кода. Где еще 2 независимых теста для базы и наследника?

Я тебе показал весь необходимый код для моего и твоего случаев.

I>>Ну и клоунада, выбрал удобный для себя интерфейс этого ThirdParty Ну да бог с ним.

V>Это не "удобный интерфейс", а те самые два

Если ты плохо понимаешь, то напомню, что интерфейс ThirdParty ты спросил у меня. Вот им и надо было пользваться.

А ты поступил с ThirdParty как со своим собственным кодом

I>>Ага, вводить лишний интерфейс чисто для тестирования

V>В этом и состоит один из способов. Характерно то, что будучи введен лишь для обеспечения тестопригодности, "лишний интерфейс" порой начинают использовать и для целевых прикладных вещей. Ведь происходящее — суть обеспечение изолированности, а оно бывает удобным не только для теста.

1 you aint gonna need it
2 keep it simple, stupid !

протестировать можно без доп. классов, без подмены сборок, без доп. интерфейсов

V>Угу. А всего два. Независимо от сложности базового класса.

Это на два больше чем необходимо

V>Протокол использования базы не факт, что примитивен. В отличие от твоего адаптера из трех строчек, на который ты умудрился написать тест. Мне бы и в голову не пришло. ЭТО примитивно.

При чем здесь база ? Ты все хочешь на какую то свою задачу спрыгнуть.

V>А где ты видел, что я его менял? Чукча писатель?

Видел.Вот твой код:

class ThirdParty {
  protected abstact int TemplateMethod();
  protected void EntryPoint() {}
}

А вот мой — http://rsdn.ru/forum/philosophy/4171862.1.aspx

Автор: Ikemefula
Дата: 24.02.11

class ThirdParty
{
  public void WriteToDatabase(string value);
}

Судя по всему у тебя или очень короткая память, или ты просто сознательно врёшь

I>>За такую "тестируемость" надо выпиливать из проекта вместе с кодом.
V>За непроходимость и предрассудки надо выпиливать.


V>Два однострочных метода наблюдаются у твоего адаптера. И да, ты такой весь довольный написал код тестирования этих двух однострочных методов. Ну поздравляю.

Это был пример. Не все декотораторы такие примитивные.

>Только я решал другую задачу — изолирование нашего прикладного кода от ненашего.

Я решил эту же задачу и вероятно тебе это крайне сложно понять

Здравствуйте, vdimas, Вы писали:

V>Ты пока проверил сам факт вызова методов целевого класса. Вместо целевого класса была заглушка. Мои поздравления, это было впечатляюще! Тестирования целевого класса не будет? Коль методы находятся в наследнике, они не пусты, что-то делают. Где тестовое покрытие этих методов? А базовый класс заведомо надежен?

Может тебе запостить сюда тесты для всего фреймворка ?

V>>>Ты напиши изолированный тест для PreAndPostDecorator, который, например, нетривиально пользует базовый ThirdPartyClass. Вот что представляет интерес для тестирования.

I>>Точно такой же подход.

V>Дык, покажи.

см выше

Здравствуйте, samius, Вы писали:

I>>Здесь нет ничего оригинального. Просто не нужно ГоФ понимать буквально.

S>Гоф тут не причем. Если объект изменил внешнее поведение, значит он не может считаться неизменяемым, вне зависимости от того, хранится ли состояние в нем самом, или еще где.

Внешнее поведение это конкретный протокол/контракт. Класс реализует протокол/контракт — реализует. Изменения в протоколе есть — нет. Нарушения контракта есть — нет. Стало быть внешнее не менялось.

Т.е. State меняет _внутреннее_ поведение как раз за счет иммутабельности.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Гоф тут не причем. Если объект изменил внешнее поведение, значит он не может считаться неизменяемым, вне зависимости от того, хранится ли состояние в нем самом, или еще где.

I>Внешнее поведение это конкретный протокол/контракт. Класс реализует протокол/контракт — реализует. Изменения в протоколе есть — нет. Нарушения контракта есть — нет. Стало быть внешнее не менялось.

То есть ты прописал изменение поведения в контракт и объявил иммутабельность? браво!

I>Т.е. State меняет _внутреннее_ поведение как раз за счет иммутабельности.

Я не понимаю, о чем ты

Здравствуйте, samius, Вы писали:

I>>Внешнее поведение это конкретный протокол/контракт. Класс реализует протокол/контракт — реализует. Изменения в протоколе есть — нет. Нарушения контракта есть — нет. Стало быть внешнее не менялось.

S>То есть ты прописал изменение поведения в контракт и объявил иммутабельность? браво!

Не валяй дурака, ладно ?

Конкретный State это только часть всего поведения, которое описывается протоколом

Поясняю — протоколы описываются без вникания в детали того, как ты будешь реализовывать. Хоть State, хоть Strategy, хоть Template Method, хоть Decorator — абсолютно фиолетово, протокол во всех случаях остаётся ровно один и тот же.

Т.е. конкретный state реализует не весь протокол, а только ЧАСТЬ его.

Хотя я не уверен, возможно ты считаешь, что правила вроде Connect->Send->Disconnect это "изменение поведения в контракт"

I>>Т.е. State меняет _внутреннее_ поведение как раз за счет иммутабельности.

S>Я не понимаю, о чем ты

Ты похоже вообще не понимаешь, что такое протокол.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>То есть ты прописал изменение поведения в контракт и объявил иммутабельность? браво!

I>Не валяй дурака, ладно ?

I>Конкретный State это только часть всего поведения, которое описывается протоколом

I>Поясняю — протоколы описываются без вникания в детали того, как ты будешь реализовывать. Хоть State, хоть Strategy, хоть Template Method, хоть Decorator — абсолютно фиолетово, протокол во всех случаях остаётся ровно один и тот же.

I>Т.е. конкретный state реализует не весь протокол, а только ЧАСТЬ его.

I>Хотя я не уверен, возможно ты считаешь, что правила вроде Connect->Send->Disconnect это "изменение поведения в контракт"

Походу ты переключился с иммутабельности на контракты.

I>>>Т.е. State меняет _внутреннее_ поведение как раз за счет иммутабельности.

S>>Я не понимаю, о чем ты

I>Ты похоже вообще не понимаешь, что такое протокол.
Походу ты не понимаешь какое отношение у иммутабельности к протоколу, раз переключился на протоколы и контракты.

Объясняю: неизменность состояния с внешней точки зрения (иммутабельность) может быть частью контракта, но неизменность контракта не есть неизменность состояния.

Здравствуйте, samius, Вы писали:

I>>Ты похоже вообще не понимаешь, что такое протокол.
S>Походу ты не понимаешь какое отношение у иммутабельности к протоколу, раз переключился на протоколы и контракты.

S>Объясняю: неизменность состояния с внешней точки зрения (иммутабельность) может быть частью контракта, но неизменность контракта не есть неизменность состояния.

Смотри, простой протокол

[] -> connect
connect -> send
connect -> disconnect
send -> send
send -> disconnect
disconnect -> []

Тебе кажется, что это я вношу в такой протокол состояние ? Очнись и пой.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Ты похоже вообще не понимаешь, что такое протокол.
S>>Походу ты не понимаешь какое отношение у иммутабельности к протоколу, раз переключился на протоколы и контракты.

S>>Объясняю: неизменность состояния с внешней точки зрения (иммутабельность) может быть частью контракта, но неизменность контракта не есть неизменность состояния.

I>Смотри, простой протокол

I>[] -> connect
I>connect -> send
I>connect -> disconnect
I>send -> send
I>send -> disconnect
I>disconnect -> []

I>Тебе кажется, что это я вношу в такой протокол состояние ? Очнись и пой.

Мне кажется что ты хочешь этот протокол реализовать иммутабельным паттерном State. Пой ты. Это твоя песня.

Здравствуйте, Ikemefula, Вы писали:


V>>Это не "удобный интерфейс", а те самые два

I>Если ты плохо понимаешь, то напомню, что интерфейс ThirdParty ты спросил у меня. Вот им и надо было пользваться.

Какой бы интерфейс ThirdParty ты не дал, каждый его метод попадает или под первый случай, или под второй. Я же сразу попытался обратить твое внимание, видя твоё, прямо скажем, непонимание вопроса, нафига вообще применяют наследование. И даже ссылки дал. Пойдись по ним предварительно.


I>2 keep it simple, stupid !

Отличный принцип, особенно в свете показанного тобой рядом настоящей задачи и, прямо скажем, спорного решения.


I>протестировать можно без доп. классов, без подмены сборок, без доп. интерфейсов

Ты пока не показал как. Ты лишь написал тест который НЕ НУЖЕН, опустив 2 НУЖНЫХ теста.


V>>Протокол использования базы не факт, что примитивен. В отличие от твоего адаптера из трех строчек, на который ты умудрился написать тест. Мне бы и в голову не пришло. ЭТО примитивно.

I>При чем здесь база ? Ты все хочешь на какую то свою задачу спрыгнуть.

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


V>>А где ты видел, что я его менял? Чукча писатель?

I>Видел.Вот твой код:

I>

I>class ThirdParty {
I>  protected abstact int TemplateMethod();
I>  protected void EntryPoint() {}
I>}
I>

I>А вот мой — http://rsdn.ru/forum/philosophy/4171862.1.aspx

Автор: Ikemefula
Дата: 24.02.11

I>

I>class ThirdParty
I>{
I>  public void WriteToDatabase(string value);
I>}
I>

Я так и думал. Двойка за внимательность.
1. protected void SomeMethod() покрывает случай public void SomeMethod()
2. Если нам от класса нужен только публичный интерфейс, то, боюсь, убедить коллег в необходимости наследования от него не удастся. Поэтому, дабы не смешить читателей, были обыграны подробности, однозначно требующие наследования. Т.е. мы взяли такой интерфейс базового класса, который явно был разработан под последующее наследование.


I>Судя по всему у тебя или очень короткая память, или ты просто сознательно врёшь

Нормально с памятью. Я уже говорил, что ты легкомысленнен и невнимателен. По ссылкам стоит ходить и аргументы оппонентов пытаться понять.


V>>Два однострочных метода наблюдаются у твоего адаптера. И да, ты такой весь довольный написал код тестирования этих двух однострочных методов. Ну поздравляю.

I>Это был пример. Не все декотораторы такие примитивные.

Хм... Я уже не знаю, как достучаться... Ты до сих пор не понял собственный код? Тебе его кто-то другой написал и забыл объяснить, что-ли?
Ты протестировал вот это PreAndPostDoerDecorator. А сие не сам декоратор, а адаптер для оных. Никак? Прочти еще раз, потом взгляни на свой

Автор: Ikemefula
Дата: 25.02.11

вариант теста и устыдись.

Чтобы протестировать PreAndPostDecorator, необходимо убедиться, что его методы PreDo/PostDo правильно обслуживают протокол базового класса, если есть желание пройтись поведенческим тестом. Либо проверять сайд-эффекты/возвращаемые значения, коль речь идет о функциональных тестах. Понимаешь, ты же не можешь в общем случае гарантировать, что там дергают только виртуальные методы, то бишь имеется возможность использования мок-фреймворков — поэтому остается либо развязка через интерфейсы, либо заглушка в чистом виде, т.е. подмена "боевого" кода на тестовый.

Единственно, что там верно сказано, после того как ты раскрыл детали, это вот это:

Очевидно, решение не самое лучшее, т.к. PreAndPostDecorator вообще не нужен.

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

В том посте, где ты раскрыл задачу, я ближе к вечеру пройдусь детально. Бо там надо вернуться к началу, собрать историю возникновения примера и разобрать твое решение. А так же показать где там разделение состояния (и есть ли там состояние вне временного на стеке , плюс не забыть вопросы тестируемости). А это не 5 минут, боюсь 0,5..1 час времени придется угробить.


>>Только я решал другую задачу — изолирование нашего прикладного кода от ненашего.

I>Я решил эту же задачу и вероятно тебе это крайне сложно понять

Пока что тем твои тестом можно подтереться, потому как тестирования собственно PreAndPostDecorator не происходит. Кому и что тут сложно понять, уже очевидно.

Здравствуйте, vdimas, Вы писали:

I>>Если ты плохо понимаешь, то напомню, что интерфейс ThirdParty ты спросил у меня. Вот им и надо было пользваться.

V>Какой бы интерфейс ThirdParty ты не дал, каждый его метод попадает или под первый случай, или под второй. Я же сразу попытался обратить твое внимание, видя твоё, прямо скажем, непонимание вопроса, нафига вообще применяют наследование.

Неясно, для чего вообще было притягивать наследование

I>>2 keep it simple, stupid !

V>Отличный принцип, особенно в свете показанного тобой рядом настоящей задачи и, прямо скажем, спорного решения.

Мое решение проще твоего

I>>протестировать можно без доп. классов, без подмены сборок, без доп. интерфейсов

V>Ты пока не показал как. Ты лишь написал тест который НЕ НУЖЕН, опустив 2 НУЖНЫХ теста.

Я показал пример, как писать тестопригодный код и как писать тесты для него.

I>>При чем здесь база ? Ты все хочешь на какую то свою задачу спрыгнуть.

V>Понимаешь, колега. Я же тебя за коллегу считаю. Если ты с самого начала поставил условие базового класса, то оно должно было быть не от балды, правильно?

Не было там условия базового класса, ты похоже в свои выдумки сам поверил

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

Я так и думал — ты сознательно изменил условие

I>>Это был пример. Не все декотораторы такие примитивные.

V>Хм... Я уже не знаю, как достучаться... Ты до сих пор не понял собственный код? Тебе его кто-то другой написал и забыл объяснить, что-ли?
V>Ты протестировал вот это PreAndPostDoerDecorator. А сие не сам декоратор, а адаптер для оных. Никак?

Хочешь сказать, что ты адаптер назвал декоторатором ? Но вообще говоря, это декоторатор.

V>Чтобы протестировать PreAndPostDecorator, необходимо убедиться, что его методы PreDo/PostDo правильно обслуживают протокол базового класса, если есть желание пройтись поведенческим тестом. Либо проверять сайд-эффекты/возвращаемые значения, коль речь идет о функциональных тестах. Понимаешь, ты же не можешь в общем случае гарантировать, что там дергают только виртуальные методы,

Проверять надо только ключевые методы. Все подряд проверять не нужно, т.к. это в принципе невозможно Если некто вызывает невиртуальный метод с какой то целью, на этапе написания тестов неясно, легальный это вызов или нет.

V>

V>Очевидно, решение не самое лучшее, т.к. PreAndPostDecorator вообще не нужен.

V>Неудивительно, надуманность твоего примера была видна невооруженным взглядом. Да еще не соответствует приведенной в конце концов задаче.

Это твое решение избыточное

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

Попробуй, посмотри хороший букварь по тестированию предварительно

V>Пока что тем твои тестом можно подтереться, потому как тестирования собственно PreAndPostDecorator не происходит. Кому и что тут сложно понять, уже очевидно.

Конечно. Его и не надо тестировать, ибо класс этот вобще не нужен ни для продакшна ни для тестирования.

Здравствуйте, samius, Вы писали:

I>>Тебе кажется, что это я вношу в такой протокол состояние ? Очнись и пой.

S>Мне кажется что ты хочешь этот протокол реализовать иммутабельным паттерном State. Пой ты. Это твоя песня.

Сначала ты ляпнул нечто вроде "ООП паттерны не перенесут иммутабельности.".

Если бы ты сказал, что в языке где нет мутабельных переменных, State нереализуем, то это совсем другой расклад, но получится в духе КО Ибо не будет полноты по Черчу.

Потом ты задним числом решил приписать мне неизвестно что, вот например "реализовать иммутабельным паттерном State"

СurrentState().Method();

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

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

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Тебе кажется, что это я вношу в такой протокол состояние ? Очнись и пой.

S>>Мне кажется что ты хочешь этот протокол реализовать иммутабельным паттерном State. Пой ты. Это твоя песня.

I>Сначала ты ляпнул нечто вроде "ООП паттерны не перенесут иммутабельности.".
Да, ляпнул. И привел тебе примеры.

I>Если бы ты сказал, что в языке где нет мутабельных переменных, State нереализуем, то это совсем другой расклад, но получится в духе КО Ибо не будет полноты по Черчу.
Полнота не требует реализуемости ООП паттернов. Она про функции

I>Потом ты задним числом решил приписать мне неизвестно что, вот например "реализовать иммутабельным паттерном State"

I>

I>СurrentState().Method();
I>

I>Вроде и ежу понятно, что речь идет о разделении обязанностей. Если задача требует изменения состояния, то это особенность _задачи_, а не паттерна, что я тебе и показал на примере протокола.
Варьировать состояние объекта — назначение паттерна State. На задачи и протоколы ты перешел. Я говорил о паттернах.
Ты же пытаешься мне втюхать альтернативное решение задачи, которую призван решать обсуждаемый паттерн.

I>Иммутабельность это способ сведения к минимуму сайт-эффектов. Никто не говорит про абсолютную иммутабельность. Вон в Эрланге её тож нет, хотя там нет мутабельных переменных.
иммутабельность это характеристика объекта.

I>Итого, какие у тебя проблемы возникают с кодом выше ? Если есть что сказать без капитанских банальностей, валяй.
Я не вижу объект, чье состояние изменяется согласно назначению паттерна State.

Здравствуйте, samius, Вы писали:


I>>Сначала ты ляпнул нечто вроде "ООП паттерны не перенесут иммутабельности.".
S>Да, ляпнул. И привел тебе примеры.

I>>Если бы ты сказал, что в языке где нет мутабельных переменных, State нереализуем, то это совсем другой расклад, но получится в духе КО Ибо не будет полноты по Черчу.
S>Полнота не требует реализуемости ООП паттернов. Она про функции

С полнотой я погорячился. Но вообще говоря это и есть твоя позиция — "в языке где нет мутабельных переменных, State нереализуем,", правильно ?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>Сначала ты ляпнул нечто вроде "ООП паттерны не перенесут иммутабельности.".
S>>Да, ляпнул. И привел тебе примеры.

I>>>Если бы ты сказал, что в языке где нет мутабельных переменных, State нереализуем, то это совсем другой расклад, но получится в духе КО Ибо не будет полноты по Черчу.
S>>Полнота не требует реализуемости ООП паттернов. Она про функции

I>С полнотой я погорячился. Но вообще говоря это и есть твоя позиция — "в языке где нет мутабельных переменных, State нереализуем,", правильно ?
Нет, это не есть моя позиция. И я ничего не утверждал о мутабельных переменных.

В таком ракурсе объект, не изменяющий свое внутреннее состояние, отлично воспринимается в виде функции и наоборот. Между делом в ООП нигде не сказано что объекты обязаны обладать изменяемым состоянием, хотя и многие ООП паттерны не перенесут иммутабельности.

Я писал об иммутабельности объекта.

Здравствуйте, samius, Вы писали:

I>>С полнотой я погорячился. Но вообще говоря это и есть твоя позиция — "в языке где нет мутабельных переменных, State нереализуем,", правильно ?
S>Нет, это не есть моя позиция. И я ничего не утверждал о мутабельных переменных.
S>

S>В таком ракурсе объект, не изменяющий свое внутреннее состояние, отлично воспринимается в виде функции и наоборот. Между делом в ООП нигде не сказано что объекты обязаны обладать изменяемым состоянием, хотя и многие ООП паттерны не перенесут иммутабельности.

S>Я писал об иммутабельности объекта.

Приведи хороший пример "объект, не изменяющий свое внутреннее состояние" ?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Я писал об иммутабельности объекта.

I>Приведи хороший пример "объект, не изменяющий свое внутреннее состояние" ?

System.String

Здравствуйте, samius, Вы писали:

I>>Приведи хороший пример "объект, не изменяющий свое внутреннее состояние" ?

S>System.String

Он не меняет внешнее состояние. Внутреннее может меняться как угодно.