Применяете ли вы Unit Testing - Философия программирования

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

T>Основная задача состоит в том, чтобы на уровне типов заставить Account иметь операцию сравнения и заставить lock выполняться сперва над меньшим операндом. И чтобы операция сравнения была представима в виде DAG.

T>Если мы присобачим к lock операнд lockContext, то мы можем сделать что-то вроде такого:
T>

T>lock(lockContext : LockContext<Empty>, account : Account<Account_Index>) {
T>   -- обычная блокировка, вернём LockContext<Pair<Account_Index,Empty>> }
T>lock(lockContext : LockContext<Pair<PrevAcc,Tail>>, account : Acccount<ThisAcc>
T>    -- этого нет в Java, но:
T>    ,dummy : TypeLevel_Less(PrevAcc,ThisAcc) := unit -- чтобы не указывать аргументом
T>    -- TypeLevel_Less переписывает пару типов в unit, если первый меньше второго
T>    -- и в ничто (давая ошибку типа) в противном случае
T>    ) {
T>   блокировка, вернём LockContext<Pair<ThisAcc,Pair<Account_Index,Empty>>>
T>}
T>

Может я чего-то недопонимаю, но все это держится на представлении о том, что программист, реализующий операцию transfer, должен внутри вызвать правильную последовательность функций lock. А потребовать от него это мы можем лишь заставив операцию transfer иметь прототип вида:

LockContext<Pair<Account_Index,Pair<Account_Index,Empty>>
transfer(from: Account, to: Account, ammount: Money) ...

Без этого требования программист вполне может по ошибке или недосмотру использовать в реализации transfer функцию lock первого вида. Т.е. надо было бы сделать так:

transfer(from,to,ammount) {
  l1 = lock(from, Empty)
  l2 = lock(l1, to)
  ...
}

а написали так:

transfer(from,to,ammount) {
  l1 = lock(from, Empty)
  l2 = lock(to,Empty)
  ...
}

Но все это идет лесом, если transfer должен будет возвращать, к примеру, состояния счетов from и to на момент завершения операции.

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

E>Может я чего-то недопонимаю, но все это держится на представлении о том, что программист, реализующий операцию transfer, должен внутри вызвать правильную последовательность функций lock. А потребовать от него это мы можем лишь заставив операцию transfer иметь прототип вида:
E>

E>LockContext<Pair<Account_Index,Pair<Account_Index,Empty>>
E>transfer(from: Account, to: Account, ammount: Money) ...
E>

И, в догонку... Об ошибках. Даже такой прототип не защитит от глупой ошибки вида:

LockContext<Pair<Account_Index,Pair<Account_Index,Empty>>
transfer(from: Account, to: Account, ammount: Money) {
  l = lock(from, lock(from, Empty))
  from.debit(ammount)
  to.credit(ammount)
  return l;
}

E>Может я чего-то недопонимаю, но все это держится на представлении о том, что программист, реализующий операцию transfer, должен внутри вызвать правильную последовательность функций lock. А потребовать от него это мы можем лишь заставив операцию transfer иметь прототип вида:
E>

E>LockContext<Pair<Account_Index,Pair<Account_Index,Empty>>
E>transfer(from: Account, to: Account, ammount: Money) ...
E>

По-моему, всё понимаешь.

E>Без этого требования программист вполне может по ошибке или недосмотру использовать в реализации transfer функцию lock первого вида. Т.е. надо было бы сделать так:
E>

E>transfer(from,to,ammount) {
E>  l1 = lock(from, Empty)
E>  l2 = lock(l1, to)
E>  ...
E>}
E>

E>а написали так:
E>

E>transfer(from,to,ammount) {
E>  l1 = lock(from, Empty)
E>  l2 = lock(to,Empty)
E>  ...
E>}
E>

Поэтому товарищи внесли LockContext в монаду, в которой происходит lock. Контекст передаётся неявно.

E>Но все это идет лесом, если transfer должен будет возвращать, к примеру, состояния счетов from и to на момент завершения операции.

Этого я не понял, прошу прощения.

Если у нас есть пары, то мы можем вернуть и пару состояний счетов.

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

T>По-моему, всё понимаешь.

Блин, после этого утверждения я немерянно вырос в собственных глазах!

E>>Но все это идет лесом, если transfer должен будет возвращать, к примеру, состояния счетов from и to на момент завершения операции.

T>Этого я не понял, прошу прощения.

T>Если у нас есть пары, то мы можем вернуть и пару состояний счетов.

Я о том, что программу может интересовать только transfer вида:

Pair<AccountState,AccountState> transfer(from, to, amount) {...}

информация о блокировках внутри transfer -- это детали реализации, которые, по-хорошему, не должны быть видны снаружи transfer-а.

E>Я о том, что программу может интересовать только transfer вида:
E>

E>Pair<AccountState,AccountState> transfer(from, to, amount) {...}
E>

E>информация о блокировках внутри transfer -- это детали реализации, которые, по-хорошему, не должны быть видны снаружи transfer-а.

За исключением тех случаев, когда они должны быть видны.

Например, условный трансфер, по условию договора. "Если на счёте Семёна окажется ровно $1000, то перевести $999 Джону, да чтобы в долг не залезть".

Поскольку в том DSEL блокировки находятся в контексте монады, то они важны только для операций с состоянием монады. Тип transfer будет

[haskell]
transfer :: Account -> Account -> LockMonad lockState lockState (AccountState,AccountState)
[haskell]

Показано равенство двух состояний блокировок и возвращаемое значение.

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

T>>Это же единовременное вложение, nes pa?

DM>n'est-ce pas

Мне кажется, thesz копировал Выбегалло. Но я тоже обратил внимание, что он написал латиницей.

Это показательный пример того, почему на рсдн флеймов больше, чем топиков

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

T>Test Driven Design/Development использует тесты, чтобы контролировать правильность внесения изменений после изменений спецификаций. Результатом обнаружения ошибки, если она была обнаружена, является примерное местоположение неправильно работающей части программы. Программа с ошибкой в тестировании может быть запущена и отдана заказчику. Ответ на вопрос "почему так" оставлен на программиста. Вероятность обнаружения ошибки связана с качеством написания тестов, которая зависит от автора теста — рядового члена команды. Это связано с большим объёмом работы по написанию тестов.
Это очень поеврхностный взгляд на тестирование.
1)ни одна версия не уходит в релиз, пока не пройдены все тесты
2)вероятность пропуска бага зависит от непокрытого тестами участка кода
3)использование тестов перед кодом позволяет один раз задумываться что код должен делать, это почти всегда приводит к сокращению написанного кода
4)есть инструменты автоматической генерации тестов (pex), которые позволяют автоматизировать whitebox тестирование

T>Итак, основная разница в том, кто ответственен за вероятность пропущенной в окончательное приложение ошибки. В случае TeDD это все члены команды, в случае TyDD это старшие (более опытные) члены команды и авторы системы типов (очень умные люди, в случае языков типа Хаскель/Coq/Agda2 — умнейшие люди планеты).
В этом плане TeDD выгоднее, так как позволяет более быстро обучаться менее опытным разработчикам.

T>Другая разница состоит в необходимости править программу до упора, пока не заработает в случае TyDD. Кому-то это нравится, кому-то нет. Мне нравится.

Аналогично в TeDD — надо править пока не проходятся все тесты. Иначе смысла в тестировании нету.

T>>Test Driven Design/Development использует тесты, чтобы контролировать правильность внесения изменений после изменений спецификаций. Результатом обнаружения ошибки, если она была обнаружена, является примерное местоположение неправильно работающей части программы. Программа с ошибкой в тестировании может быть запущена и отдана заказчику. Ответ на вопрос "почему так" оставлен на программиста. Вероятность обнаружения ошибки связана с качеством написания тестов, которая зависит от автора теста — рядового члена команды. Это связано с большим объёмом работы по написанию тестов.
G>Это очень поеврхностный взгляд на тестирование.

Ты просто не дал себе труда обдумать.

G>1)ни одна версия не уходит в релиз, пока не пройдены все тесты

Но может? Может. У меня так и написано.

G>2)вероятность пропуска бага зависит от непокрытого тестами участка кода

И от квалификации пишущего тесты. Он может создать тест, который заходит в процедуру с делением на входное значение и не подать туда 0. Покрытие есть, есть и ошибка.

G>3)использование тестов перед кодом позволяет один раз задумываться что код должен делать, это почти всегда приводит к сокращению написанного кода

Также относится и к другому методу, поэтому перпендикулярно дискуссии.

G>4)есть инструменты автоматической генерации тестов (pex), которые позволяют автоматизировать whitebox тестирование

И вывод типов с Квикчеком, ага.

Кстати, pex применим только к строго типизированным языкам. Попробуй натравить его на Smalltalk, хотя бы гипотетически.

Поэтому аргумент насчёт pex мы отбросим, как неорганизованный — он относится только к части языков, где может быть TDD.

T>>Итак, основная разница в том, кто ответственен за вероятность пропущенной в окончательное приложение ошибки. В случае TeDD это все члены команды, в случае TyDD это старшие (более опытные) члены команды и авторы системы типов (очень умные люди, в случае языков типа Хаскель/Coq/Agda2 — умнейшие люди планеты).
G>В этом плане TeDD выгоднее, так как позволяет более быстро обучаться менее опытным разработчикам.

В этом плане TyDD выгоднее, поскольку на тебя работают умнейшие люди планеты. Они, как бы, незримо присутствуют в команде.

T>>Другая разница состоит в необходимости править программу до упора, пока не заработает в случае TyDD. Кому-то это нравится, кому-то нет. Мне нравится.

G>Аналогично в TeDD — надо править пока не проходятся все тесты. Иначе смысла в тестировании нету.

Если Development — TeDDv, — да, надо править. Если Design — TeDDn — нет, не надо править.

TyDD такая штука, что заставит тебя сделать и Development, хоть ты и начинал с Design.

Так что, иди, разбирайся, что же такое TDD.

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

G>>1)ни одна версия не уходит в релиз, пока не пройдены все тесты
T>Но может? Может. У меня так и написано.
Это зависит от того как построен процесс разработки. По-хорошему — не может. Кроме автоматизированного тестирования есть еще тестирования людями, а они получают только билд со всеми автоматическими успешными тестами.
Некоторые системы сборки, как TFS, позволяют запретить коммиты в репозитарий при нарушенном билде.

G>>2)вероятность пропуска бага зависит от непокрытого тестами участка кода
T>И от квалификации пишущего тесты. Он может создать тест, который заходит в процедуру с делением на входное значение и не подать туда 0. Покрытие есть, есть и ошибка.
Самое смешное что все будет ОК, если нету сценариев, когда в эту функцию передается 0

А вообще можно pex натравить на такой метод, быстро все найдет.

G>>3)использование тестов перед кодом позволяет один раз задумываться что код должен делать, это почти всегда приводит к сокращению написанного кода
T>Также относится и к другому методу, поэтому перпендикулярно дискуссии.
У меня есть сомнения что системой типов можно адекватно выразить что делает код, в случае более-менее большого куска.
Например я писал интеграционный тест для автоматической регистрации:
сначала вызывается метод регистрации (на него непосредственно приходит управление),
потом вызывается метод с нужными параметрами, полученными "из текста письма" (на самом деле там фейк, который письма никуда не отправляет),
потом метод логина в систему с теми же именем пользователя и пароля что и при регистрации.
Соотвественно проверялось что логин в таком случае будет успешен.
Как такое системой типов выразить?

T>Поэтому аргумент насчёт pex мы отбросим, как неорганизованный — он относится только к части языков, где может быть TDD.
Не понял логики.. pex — генератор тестов, почему его отбрасывать надо?

T>>>Итак, основная разница в том, кто ответственен за вероятность пропущенной в окончательное приложение ошибки. В случае TeDD это все члены команды, в случае TyDD это старшие (более опытные) члены команды и авторы системы типов (очень умные люди, в случае языков типа Хаскель/Coq/Agda2 — умнейшие люди планеты).
G>>В этом плане TeDD выгоднее, так как позволяет более быстро обучаться менее опытным разработчикам.
T>В этом плане TyDD выгоднее, поскольку на тебя работают умнейшие люди планеты. Они, как бы, незримо присутствуют в команде.
Умнейших людей планеты на всех не хватит, а софт кому-то писать надо.

T>>>Другая разница состоит в необходимости править программу до упора, пока не заработает в случае TyDD. Кому-то это нравится, кому-то нет. Мне нравится.

G>>Аналогично в TeDD — надо править пока не проходятся все тесты. Иначе смысла в тестировании нету.

T>Если Development — TeDDv, — да, надо править. Если Design — TeDDn — нет, не надо править.
T>TyDD такая штука, что заставит тебя сделать и Development, хоть ты и начинал с Design.
ты серьезно считаешь что можно релизить код, который не проходит процедуру контроля качества?

T>Так что, иди, разбирайся, что же такое TDD.

Не по адресу.

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

T>>Поэтому аргумент насчёт pex мы отбросим, как неорганизованный — он относится только к части языков, где может быть TDD.
G>Не понял логики.. pex — генератор тестов, почему его отбрасывать надо?

Ну, вообще говоря, без статической типизации Pex работать бы не смог. Я так понял, что Pex — это попытка получить все что возможно от доказывателя теорем в условиях системы типов, для которой все статически доказать нельзя, но автоматически сгенерировать тесты можно.
Да и к TDD он имеет весьма опосредованное отношение — если писать тесты раньше чем код — много ли от Pex-а будет толку?

... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>

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

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

T>>>Поэтому аргумент насчёт pex мы отбросим, как неорганизованный — он относится только к части языков, где может быть TDD.
G>>Не понял логики.. pex — генератор тестов, почему его отбрасывать надо?

K>Ну, вообще говоря, без статической типизации Pex работать бы не смог. Я так понял, что Pex — это попытка получить все что возможно от доказывателя теорем в условиях системы типов, для которой все статически доказать нельзя, но автоматически сгенерировать тесты можно.
Вообще говоря почти все автоматизированное тестирования от недостатка статических проверок.

K>Да и к TDD он имеет весьма опосредованное отношение — если писать тесты раньше чем код — много ли от Pex-а будет толку?
Дофига. Так как можно писать тесты для success сценариев, а pex может обнаружить все fail сценарии.

Мне показалось или вы противопоставляете тестирование и типизацию?

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

G>Вообще говоря почти все автоматизированное тестирования от недостатка статических проверок.

Да.

G>Мне показалось или вы противопоставляете тестирование и типизацию?

Мне показалось, что тут вся ветка про тестирование против типизации.

... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>

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

T>>>>>Читай — выражены в виде типов.
G>>>>Это не единственный способ выражения контрактов.

T>>>Ну, вырази контракт "не должно быть deadlock".

E>>Можно попросить провести маленький ликбез в порядке просвящения? Вот есть хорошая задача: даны два банковских счета и нужно провести операцию перевода денег с одного на другой. На псевдокоде это выражается приблизительно так:
...
E>>Данный код приводит к тупикам.

T>http://www.cs.st-andrews.ac.uk/~eb/drafts/icfp08.pdf

T>Вот пример блокировки оттуда:
...
E>>Как можно описать контракт для типов Account и/или операции transfer, чтобы гарантировать, что операция не будет вести к тупикам?

T>Упорядочить блокируемые ресурсы.
...
T>Основная задача состоит в том, чтобы на уровне типов заставить Account иметь операцию сравнения и заставить lock выполняться сперва над меньшим операндом. И чтобы операция сравнения была представима в виде DAG.

T>Если мы присобачим к lock операнд lockContext, то мы можем сделать что-то вроде такого:
T>

T>lock(lockContext : LockContext<Empty>, account : Account<Account_Index>) { обычная блокировка, вернём LockContext<Pair<Account_Index,Empty>> }
T>lock(lockContext : LockContext<Pair<PrevAcc,Tail>>, account : Acccount<ThisAcc>
T>    -- этого нет в Java, но:
T>    ,dummy : TypeLevel_Less(PrevAcc,ThisAcc) := unit -- чтобы не указывать аргументом
T>    -- TypeLevel_Less переписывает пару типов в unit, если первый меньше второго
T>    -- и в ничто (давая ошибку типа) в противном случае
T>    ) {
T>   блокировка, вернём LockContext<Pair<ThisAcc,Pair<Account_Index,Empty>>>
T>}
T>

мне вот стало интересно как там у умнейших людей планеты обстоят дела с раздельной компиляцией

T>>

T>>lock(lockContext : LockContext<Empty>, account : Account<Account_Index>) { обычная блокировка, вернём LockContext<Pair<Account_Index,Empty>> }
T>>lock(lockContext : LockContext<Pair<PrevAcc,Tail>>, account : Acccount<ThisAcc>
T>>    -- этого нет в Java, но:
T>>    ,dummy : TypeLevel_Less(PrevAcc,ThisAcc) := unit -- чтобы не указывать аргументом
T>>    -- TypeLevel_Less переписывает пару типов в unit, если первый меньше второго
T>>    -- и в ничто (давая ошибку типа) в противном случае
T>>    ) {
T>>   блокировка, вернём LockContext<Pair<ThisAcc,Pair<Account_Index,Empty>>>
T>>}
T>>

SD>мне вот стало интересно как там у умнейших людей планеты обстоят дела с раздельной компиляцией

Отлично!

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

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

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

G>>>1)ни одна версия не уходит в релиз, пока не пройдены все тесты
T>>Но может? Может. У меня так и написано.
G>Это зависит от того как построен процесс разработки. По-хорошему — не может. Кроме автоматизированного тестирования есть еще тестирования людями, а они получают только билд со всеми автоматическими успешными тестами.
G>Некоторые системы сборки, как TFS, позволяют запретить коммиты в репозитарий при нарушенном билде.

Иными словами, дело процесса.

Ты, видимо, воспринимаешь процесс, как нечто железное, которое нельзя преодолеть.

G>>>2)вероятность пропуска бага зависит от непокрытого тестами участка кода
T>>И от квалификации пишущего тесты. Он может создать тест, который заходит в процедуру с делением на входное значение и не подать туда 0. Покрытие есть, есть и ошибка.
G>Самое смешное что все будет ОК, если нету сценариев, когда в эту функцию передается 0

G>А вообще можно pex натравить на такой метод, быстро все найдет.

Примени pex к тексту на Перле.

G>>>3)использование тестов перед кодом позволяет один раз задумываться что код должен делать, это почти всегда приводит к сокращению написанного кода
T>>Также относится и к другому методу, поэтому перпендикулярно дискуссии.
G>У меня есть сомнения что системой типов можно адекватно выразить что делает код, в случае более-менее большого куска.
G>Например я писал интеграционный тест для автоматической регистрации:
G>сначала вызывается метод регистрации (на него непосредственно приходит управление),
G>потом вызывается метод с нужными параметрами, полученными "из текста письма" (на самом деле там фейк, который письма никуда не отправляет),
G>потом метод логина в систему с теми же именем пользователя и пароля что и при регистрации.
G>Соотвественно проверялось что логин в таком случае будет успешен.
G>Как такое системой типов выразить?

Видишь ли, если я начну тебе объяснять, то ты меня "перестанешь понимать уже на пятой странице".

Тем не менее: http://blog.sigfpe.com/2009/02/beyond-monads.html
У нас есть такая волшебная "точка с запятой" под названием >>=, она же bind. Она соединяет "вычисление из контекста A в контекст B" с "вычислением из контекста B в контекст C".

Например, мы можем перейти из контекста "ничего не сделано" в контекст "получили параметры". Затем мы можем перейти в контекст "произвели логин". И тп.

Нет ничего магического.

Кстати, в Sing# примерно так и сделано. Только, как всегда, криво и косо.

T>>Поэтому аргумент насчёт pex мы отбросим, как неорганизованный — он относится только к части языков, где может быть TDD.
G>Не понял логики.. pex — генератор тестов, почему его отбрасывать надо?

Он не работает в случае языков типа Smalltalk. Он работает только для языков, где есть статические типы, а там и TyDD можно пользоваться.

T>>>>Итак, основная разница в том, кто ответственен за вероятность пропущенной в окончательное приложение ошибки. В случае TeDD это все члены команды, в случае TyDD это старшие (более опытные) члены команды и авторы системы типов (очень умные люди, в случае языков типа Хаскель/Coq/Agda2 — умнейшие люди планеты).
G>>>В этом плане TeDD выгоднее, так как позволяет более быстро обучаться менее опытным разработчикам.
T>>В этом плане TyDD выгоднее, поскольку на тебя работают умнейшие люди планеты. Они, как бы, незримо присутствуют в команде.
G>Умнейших людей планеты на всех не хватит, а софт кому-то писать надо.

Ну что ты за глупости говоришь.

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

T>>>>Другая разница состоит в необходимости править программу до упора, пока не заработает в случае TyDD. Кому-то это нравится, кому-то нет. Мне нравится.

G>>>Аналогично в TeDD — надо править пока не проходятся все тесты. Иначе смысла в тестировании нету.

T>>Если Development — TeDDv, — да, надо править. Если Design — TeDDn — нет, не надо править.
T>>TyDD такая штука, что заставит тебя сделать и Development, хоть ты и начинал с Design.
G>ты серьезно считаешь что можно релизить код, который не проходит процедуру контроля качества?

Да.

Это часть процесса, который можно отменить и/или подправить в текущий момент.

T>>Так что, иди, разбирайся, что же такое TDD.

G>Не по адресу.

У тебя ещё и чувства юмора нет. Ох.

T>>>Это же единовременное вложение, nes pa?
DM>>n'est-ce pas
L>Мне кажется, thesz копировал Выбегалло. Но я тоже обратил внимание, что он написал латиницей.
L>Это показательный пример того, почему на рсдн флеймов больше, чем топиков

thesz взял это выражение из одного из текстов Yello (конкретно, Bostich), где в своё время было nes pa (а сейчас уже того варианта не найти).

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

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

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

G>>>>1)ни одна версия не уходит в релиз, пока не пройдены все тесты
T>>>Но может? Может. У меня так и написано.
G>>Это зависит от того как построен процесс разработки. По-хорошему — не может. Кроме автоматизированного тестирования есть еще тестирования людями, а они получают только билд со всеми автоматическими успешными тестами.
G>>Некоторые системы сборки, как TFS, позволяют запретить коммиты в репозитарий при нарушенном билде.

T>Иными словами, дело процесса.
T>Ты, видимо, воспринимаешь процесс, как нечто железное, которое нельзя преодолеть.
Это уже зависит от того, кто процессом управляет... Но это уже тема для другого раздела форума.

G>>>>2)вероятность пропуска бага зависит от непокрытого тестами участка кода
T>>>И от квалификации пишущего тесты. Он может создать тест, который заходит в процедуру с делением на входное значение и не подать туда 0. Покрытие есть, есть и ошибка.
G>>Самое смешное что все будет ОК, если нету сценариев, когда в эту функцию передается 0

G>>А вообще можно pex натравить на такой метод, быстро все найдет.

T>Примени pex к тексту на Перле.
Pex работает на уровне IL, а не на исходниках. Когда perl научится в .NET компилироваться, тогда посмотрим

Хотя и там вряд ли получится.

G>>>>3)использование тестов перед кодом позволяет один раз задумываться что код должен делать, это почти всегда приводит к сокращению написанного кода
T>>>Также относится и к другому методу, поэтому перпендикулярно дискуссии.
G>>У меня есть сомнения что системой типов можно адекватно выразить что делает код, в случае более-менее большого куска.
G>>Например я писал интеграционный тест для автоматической регистрации:
G>>сначала вызывается метод регистрации (на него непосредственно приходит управление),
G>>потом вызывается метод с нужными параметрами, полученными "из текста письма" (на самом деле там фейк, который письма никуда не отправляет),
G>>потом метод логина в систему с теми же именем пользователя и пароля что и при регистрации.
G>>Соотвественно проверялось что логин в таком случае будет успешен.
G>>Как такое системой типов выразить?

T>Видишь ли, если я начну тебе объяснять, то ты меня "перестанешь понимать уже на пятой странице".

Мне для этого понадобилась пара десятков строк.

T>Тем не менее: http://blog.sigfpe.com/2009/02/beyond-monads.html
T>У нас есть такая волшебная "точка с запятой" под названием >>=, она же bind. Она соединяет "вычисление из контекста A в контекст B" с "вычислением из контекста B в контекст C".
T>Например, мы можем перейти из контекста "ничего не сделано" в контекст "получили параметры". Затем мы можем перейти в контекст "произвели логин". И тп.
T>Нет ничего магического.
Ну то что подобное можно написать на хаскеле я не сомневаюсь (было бы странно иначе), но как обеспечить статическую проверку сценария?
Стоит учеть, что каджый метод в отдельности имеет кучу сценариев работы.

T>>>Поэтому аргумент насчёт pex мы отбросим, как неорганизованный — он относится только к части языков, где может быть TDD.
G>>Не понял логики.. pex — генератор тестов, почему его отбрасывать надо?
T>Он не работает в случае языков типа Smalltalk. Он работает только для языков, где есть статические типы, а там и TyDD можно пользоваться.
Ну в .NET и java есть статические типы, но именно в них TeDD находит такое широкое применнение.

T>>>Если Development — TeDDv, — да, надо править. Если Design — TeDDn — нет, не надо править.
T>>>TyDD такая штука, что заставит тебя сделать и Development, хоть ты и начинал с Design.
G>>ты серьезно считаешь что можно релизить код, который не проходит процедуру контроля качества?
T>Да.
T>Это часть процесса, который можно отменить и/или подправить в текущий момент.
Слабоватый агрумент. На сильную типизацию при желании тоже забить можно, в тестах ассерты закомменитить итп.

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

M>Слишком много "но" у этой методы, чтобы успешно влезать в конвейер разработки.

Не благоволите ли перечислить хотя бы первый десяток?

ЗЫ Только пожалуйста без употреблявшихся выше фокусов типа "утюг — фигня потому что на нем неудобно готовить кофе".

T>>Иными словами, дело процесса.
T>>Ты, видимо, воспринимаешь процесс, как нечто железное, которое нельзя преодолеть.
G>Это уже зависит от того, кто процессом управляет... Но это уже тема для другого раздела форума.

Возможность не зависит от того, кто управляет процессом.

T>>Тем не менее: http://blog.sigfpe.com/2009/02/beyond-monads.html
T>>У нас есть такая волшебная "точка с запятой" под названием >>=, она же bind. Она соединяет "вычисление из контекста A в контекст B" с "вычислением из контекста B в контекст C".
T>>Например, мы можем перейти из контекста "ничего не сделано" в контекст "получили параметры". Затем мы можем перейти в контекст "произвели логин". И тп.
T>>Нет ничего магического.
G>Ну то что подобное можно написать на хаскеле я не сомневаюсь (было бы странно иначе), но как обеспечить статическую проверку сценария?
G>Стоит учеть, что каджый метод в отдельности имеет кучу сценариев работы.

Да, бляха муха, возьми и напиши. Чего ты меня мучаешь в стиле "как написать? вот, как ты написал, я это и так понимаю, а как написать?"

В детстве у нас похожий сценарий назывался "купи слона".

"Я понимаю, что ты на Хаскеле это напишешь, но ты купи слона!"

T>>>>Поэтому аргумент насчёт pex мы отбросим, как неорганизованный — он относится только к части языков, где может быть TDD.
G>>>Не понял логики.. pex — генератор тестов, почему его отбрасывать надо?
T>>Он не работает в случае языков типа Smalltalk. Он работает только для языков, где есть статические типы, а там и TyDD можно пользоваться.
G>Ну в .NET и java есть статические типы, но именно в них TeDD находит такое широкое применнение.

Ты и с историей TeDD не знаком. Он же родом из Смолтока, Кент Бек (который экстремальное программирование) его автор.

В .Net и Java отвратительная статическая типизация, это я тебе ответственно заявляю и здесь многие поддержат это моё мнение. Неудивительно, что в них применяется метод из совсем уж слабых языков программирования.

T>>>>Если Development — TeDDv, — да, надо править. Если Design — TeDDn — нет, не надо править.
T>>>>TyDD такая штука, что заставит тебя сделать и Development, хоть ты и начинал с Design.
G>>>ты серьезно считаешь что можно релизить код, который не проходит процедуру контроля качества?
T>>Да.
T>>Это часть процесса, который можно отменить и/или подправить в текущий момент.
G>Слабоватый агрумент. На сильную типизацию при желании тоже забить можно, в тестах ассерты закомменитить итп.

Ну, давай, забей на статическую типизацию.

Отключи её, бляха муха, в твоей программе на C#.

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

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

T>>>>>Поэтому аргумент насчёт pex мы отбросим, как неорганизованный — он относится только к части языков, где может быть TDD.
G>>>>Не понял логики.. pex — генератор тестов, почему его отбрасывать надо?
T>>>Он не работает в случае языков типа Smalltalk. Он работает только для языков, где есть статические типы, а там и TyDD можно пользоваться.
G>>Ну в .NET и java есть статические типы, но именно в них TeDD находит такое широкое применнение.

T>Ты и с историей TeDD не знаком. Он же родом из Смолтока, Кент Бек (который экстремальное программирование) его автор.
Отлично знаком. И что что родом из смолтока? все ООП родом из смолтока, правда на смолток нифига не похоже...

T>В .Net и Java отвратительная статическая типизация, это я тебе ответственно заявляю и здесь многие поддержат это моё мнение.
Да и я поддержу.

T>Неудивительно, что в них применяется метод из совсем уж слабых языков программирования.
А вот тут не согласен. Тестирование и TDD вполне достойные методы сами по себе.
Ты все пытаешься доказать что при хорошей системе типов они не нужны, но как-то неубедительно.
(Если че — я не пытаюсь доказать обратное)

От:	eao197	http://eao197.blogspot.com
Дата:	23.06.09 10:45
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	23.06.09 10:49
Оценка:

От:	thesz	http://thesz.livejournal.com
Дата:	23.06.09 11:19
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	23.06.09 11:31
Оценка:

От:	thesz	http://thesz.livejournal.com
Дата:	23.06.09 11:54
Оценка:

От:	lomeo	http://lomeo.livejournal.com/
Дата:	23.06.09 12:45
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	23.06.09 13:40
Оценка: