Здравствуйте, Sinclair, Вы писали:
S>Вот несколько лет назад на RSDN пробегал прикольный пример DDT — где автор коммитил логи успешного выполнения тест-кейзов в SVN. Это давало автоматический regression: как только менялось хоть что-то, SVN видел change. При этом совершенно не требовалось мучительно изобретать тесты по спецификации, а потом сводить их с реализацией (которая запросто может отличаться от ожиданий. Неужто никто не правил SRS по результатам неудачных попыток реализовать его?).
Это я был
Тесты для немерле примерно также устроены.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, matumba, Вы писали:
M>Я так понимаю, речь идёт об оценке производительности и не упала ли она? Regression — какой-то неудачный термин, degradation test был бы уместнее.
Нет. Производительность тут ни каким боком.
А регрессия это когда что-то где-то поменял и что-то другое сломалось.
Это и ловится.
M>Но это на отлаженном коде!
Ну да. Чтобы получить эталонный лог нужно отладить код.
M>И требующем всё же некой мат.обработки.
Чё?
M>А нам бы вообще добиться верного результата.
А что с этим есть проблемы?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, thesz, Вы писали:
T>>Я же не про Библию (да ещё и Старый Завет) говорил. В ней, действительно, совсем ничего радостного нет.
FR>Так современные психологи и социологи тоже говорят Счастье — прибежище идиотов
Есть другое мнение: между IQ и удовольствием от жизни связь настолько прямая, что людей с очень высоким IQ среди так называемых "успешных" найти очень сложно. Они настолько довольны жизнью, что им многое пофиг, всё, что им надо, они могут добиться своими силами по необходимости.
Это совпадает с китайским определением истинного мудреца, для которого только время преграда.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, thesz, Вы писали:
T>>>>Тем не менее, потерять своё время и время пользователя (наличие логов просаживает производительность программы) на их поиск ты считаешь возможным. G>>>Логи только при отладке, в релизе отключаются. T>>И что, неужто дедлоков у заказчиков не было? Ни за что не поверю. G>Конечно было. Даже было такое что локально воспроизвести ситуацию не удавалось. G>Ну отправили заказчикам дебажный бинарь, а потом по логам достаточно быстро нашли причину.
И это считается нормальным.
T>>>>Да ты что! ТЫ ещё и на полном серьёзе считаешь, что ты так меньше пишешь? G>>>При фиксированном времени раздумий — да. T>>Иными словами, ты признаешь, что тебя работа задалбывает настолько, что даже нет времени подумать. G>Не вижу связи.
Ну, и ладно.
T>>>>Ты взгляни на сорцы той CbCC, там всего строк триста, насколько я помню. G>>>Что такое CbCC? T>>Correct by Construction Concurrency. G>Я примерно на 5 странице перестал понимать что там написано.
Во-от.
Я на Software People специально ходил на доклады товарищей из Agile, в частности и про TDD.
Уровень образования чудовищно низок.
Люди, пишущие на Perl, не знают, что такое REPL. Полный абзац.
Здравствуйте, thesz, Вы писали:
G>>Конечно было. Даже было такое что локально воспроизвести ситуацию не удавалось. G>>Ну отправили заказчикам дебажный бинарь, а потом по логам достаточно быстро нашли причину. T>И это считается нормальным.
Да потому что альтернативы автоматизированному тестированию это:
1) Абсолютно глюсчный бинарь, который "и не раз еще вернется", и не важно от кого от заказчика либо
от локальных тестеров.
2) Самому до посинения кликать мышкой и клацать по клавиатуре.
3) Освоить тулзы с суровой типизацией aka cтать таким же суровым как thesz.
Да третий вариант очень интересный, можно подчерпнуть множество полезных техник и подходов,
применимых не только с использованием Haskell, но есть несколько минусов.
Как минимум есть множество задач, связанных с взаимодействием с множеством сторонних библиотек и платформ. В этих
случаях мне кажется гораздо быстрее использовать автоматизированное тестирование, нежли надеятся на авось.
T>Получается, что ты пользуешься TDD не из-за того, что сознательно выбрал, а из-за того, что не понимаешь альтернатив.
Я вот не помню того момента как я учил паскаль. Точно знаю что до универа я знал только С и Basic, а в универе я
уже первую программу на паскале писал за деньги однокурсникам. С PL/SQL я тоже как-то пришел и сразу в продакшен стал
лить код. И опять же деньги.
У type driven очень не нулевой порог входа.
Тут с людьми приходится работать которым система контроля версий дается с трудом, не говоря уже о CbCC,
Haskell и сопутствующих технологиях.
T>Э-эх.
Компросисс.
Оффтопик: T>Уровень образования чудовищно низок. T>Люди, пишущие на Perl, не знают, что такое REPL. Полный абзац.
О спасибо. Составляю тут набор вопросов для отбора стажеров. Хочется чтобы люди с пользой провели время в гугле,
и пока отвечают, приобщались к прекрасному. Что такое REPL — ооотличный вопрос.
-- Главное про деструктор копирования не забыть --
Здравствуйте, thesz, Вы писали:
T>Есть другое мнение: между IQ и удовольствием от жизни связь настолько прямая, что людей с очень высоким IQ среди так называемых "успешных" найти очень сложно. Они настолько довольны жизнью, что им многое пофиг, всё, что им надо, они могут добиться своими силами по необходимости.
Ну между мнением и исследованиями есть небольшая такая разница
Если серъезно есть корреляция между степенью аутотеличности и степенью счастья, а IQ тут ни причем.
Слово «аутотелический» состоит из двух греческих корней: «ауто» (сам, самостоятельный) и «телос» (цель). Аутотелическая деятельность – это деятельность, которой мы занимаемся ради нее самой, поскольку нашей основной целью является опыт данной деятельности. Например, если бы я играл в шахматы, только для того чтобы получить удовольствие от игры, то игра была бы для меня аутотелическим опытом. В то время как, если бы я играл на деньги или чтобы завоевать высокое место в шахматном мире, то та же самая игра была бы экзотелическим опытом, то есть мотивированным внешними целями. Что касается аутотелической личности, то она означает человека, который в основном занимается чем-то ради самого этого занятия, а не для того чтобы достичь какой-то внешней цели.
Здравствуйте, thesz, Вы писали:
T>Я на Software People специально ходил на доклады товарищей из Agile, в частности и про TDD. T>Уровень образования чудовищно низок.
Как связаны уровень образования и TDD?
T>Люди, пишущие на Perl, не знают, что такое REPL. Полный абзац.
Люди пишущие на <название языка> не знают что такое <какой-нить акроним>. Можно написать генератор таких фраз, примено 90% из них будут верны.
T>Смотрим на твои сообщения: "ты просто не понимаешь TDD
". T>Выясняется, что пропонент TDD, которое Test Driven Design, не может понять TDD, которое Type Driven Design.
С чего ты взял?
T>Получается, что ты пользуешься TDD не из-за того, что сознательно выбрал, а из-за того, что не понимаешь альтернатив. T>Да и не желаешь, поскольку начальство довольно не будет
. T>Э-эх.
Да ладно, будь с собой честен. Сколько языков поддерживает Type Driven Design в таком виде? Видимо только Haskell.
А есть у Haskell фреймворк уровня ASP.NET? Есть ли готовые платформы вроде SharePoint? Можно ли программу на Haskell запускать в браузере, как Silverlight?
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, kmmbvnr, Вы писали:
M>>> "морда к базе" с транзакциями — и то уже проблема!
K>>Тестировал морды к базе. IoC контейнеры и Mock фрейворки рулят.
M>Видите — уже привлекается IoC, про которое опять ни слова от продвигателей TDD (а существующую систему без IoC вообще никто переписывать не будет). Но суть остаётся та же: юнит тестинг делать желательно, если на это есть ресурсы, покрытие тестов вас удовлетворяет и что объект теста настолько нестабилен, что имеет смысл держать его в узде.
Я не согласен с вашей фразой, отдельно по частям и вообще полностью.
M>уже привлекается IoC
Если я привлеку ASP.NET для написания вебсайтов, что теперь Ritch Internet Application есть вселенское зло?
IoC архитектура привлекается в основном не ради тестирования. Удобство для автоматизированного тестирования получаем for free.
Тестировать можно и без IoC, и без тестовых фреймворков, и вообще руками все нажимать. Но зачем?
M> TDD ... существующую систему
Употребление TDD рядом с "Существующей системой", просто некорректно. Чувствуется традиционное заблуждение что unit-тесты эквивалентно TDD.
M> если на это есть ресурсы Лично у меня
с автоматическими тестами производительность больше чем без тестов. Мне не понятно почему это тесты требуют больших ресурсов.
M> покрытие тестов вас удовлетворяет
Любое покрытие тестами является более удовлетворительным чем их полное отсутствие.
M> объект теста настолько нестабилен
Если у мне не понятно как делать 10% проекта, и я хожу кругами переделывая это по несколько раз, это не повод не тестировать остальные 90%
M>А вы не могли бы найти по каким-то ключевым словам, плиз? Боюсь, что я по "фаулер" и "руби" вряд ли найду что-то однозначное.
matumba,
K>>Тестировал морды к базе. IoC контейнеры и Mock фрейворки рулят.
M>Видите — уже привлекается IoC, про которое опять ни слова от продвигателей TDD (а существующую систему без IoC вообще никто переписывать не будет).
Есть неинтрузивные ioc-контейнеры, например Autofac для .net. И наличие ioc ортогонально наличию юнит-тестов вообще. ioc + mocks просто удобнее в плане реализации юниттестов.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, thesz, Вы писали:
T>>Я на Software People специально ходил на доклады товарищей из Agile, в частности и про TDD. T>>Уровень образования чудовищно низок. G>Как связаны уровень образования и TDD?
Type Driven Design? Напрямую.
T>>Люди, пишущие на Perl, не знают, что такое REPL. Полный абзац. G>Люди пишущие на <название языка> не знают что такое <какой-нить акроним>. Можно написать генератор таких фраз, примено 90% из них будут верны.
Ты уж извини, но REPL для динамических языков дело святое.
T>>Смотрим на твои сообщения: "ты просто не понимаешь TDD
T>>Получается, что ты пользуешься TDD не из-за того, что сознательно выбрал, а из-за того, что не понимаешь альтернатив. T>>Да и не желаешь, поскольку начальство довольно не будет
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, thesz, Вы писали:
T>>Есть другое мнение: между IQ и удовольствием от жизни связь настолько прямая, что людей с очень высоким IQ среди так называемых "успешных" найти очень сложно. Они настолько довольны жизнью, что им многое пофиг, всё, что им надо, они могут добиться своими силами по необходимости.
FR>Ну между мнением и исследованиями есть небольшая такая разница
FR>Если серъезно есть корреляция между степенью аутотеличности и степенью счастья, а IQ тут ни причем.
The other point I found interesting was when Gladwell alluded to the fact that most brilliant children don't become "successful" but usually have "happy" lives. He suggests that it is an almost deliberate choice, i.e. because they were brilliant they realized the combination of sacrifices and luck needed to become successful, and determined it just wasn't worth it.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Читай — выражены в виде типов. G>>Это не единственный способ выражения контрактов.
T>Ну, вырази контракт "не должно быть deadlock".
Можно попросить провести маленький ликбез в порядке просвящения? Вот есть хорошая задача: даны два банковских счета и нужно провести операцию перевода денег с одного на другой. На псевдокоде это выражается приблизительно так:
Данный код приводит к тупикам. Как можно описать контракт для типов Account и/или операции transfer, чтобы гарантировать, что операция не будет вести к тупикам?
Если можно на пальцах с применением C/Java- или Pascal-, или Python-онобразного псевдокода. А то у меня от коротких примеров на Haskell крышу сносит.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
K>Как минимум есть множество задач, связанных с взаимодействием с множеством сторонних библиотек и платформ. В этих K>случаях мне кажется гораздо быстрее использовать автоматизированное тестирование, нежли надеятся на авось.
Я не против.
Но с альтернативой надо быть знакомым.
T>>Получается, что ты пользуешься TDD не из-за того, что сознательно выбрал, а из-за того, что не понимаешь альтернатив. K>Я вот не помню того момента как я учил паскаль. Точно знаю что до универа я знал только С и Basic, а в универе я K>уже первую программу на паскале писал за деньги однокурсникам. С PL/SQL я тоже как-то пришел и сразу в продакшен стал K>лить код. И опять же деньги. K>У type driven очень не нулевой порог входа.
Сейчас попробую сформулировать получше различия.
Test Driven Design/Development использует тесты, чтобы контролировать правильность внесения изменений после изменений спецификаций. Результатом обнаружения ошибки, если она была обнаружена, является примерное местоположение неправильно работающей части программы. Программа с ошибкой в тестировании может быть запущена и отдана заказчику. Ответ на вопрос "почему так" оставлен на программиста. Вероятность обнаружения ошибки связана с качеством написания тестов, которая зависит от автора теста — рядового члена команды. Это связано с большим объёмом работы по написанию тестов.
Type Driven Design/Development использует типы, чтобы контролировать правильность внесения изменения после изменения спецификаций. Результатом обнаружения ошибки, если она была обнаружена, является местоположение неправильно работающей части программы. Программа с ошибкой в типах не может быть запущена и отдана заказчику. Ответ на вопрос "почему так" может быть получен из диагностики системы. Вероятность обнаружения ошибки связана с качеством системы типов и точностью задания спецификации типов уровнем выше, что может быть выполнено людьми более опытными, чем рядовой член команды, поскольку объём работы меньше.
Итак, основная разница в том, кто ответственен за вероятность пропущенной в окончательное приложение ошибки. В случае TeDD это все члены команды, в случае TyDD это старшие (более опытные) члены команды и авторы системы типов (очень умные люди, в случае языков типа Хаскель/Coq/Agda2 — умнейшие люди планеты).
Другая разница состоит в необходимости править программу до упора, пока не заработает в случае TyDD. Кому-то это нравится, кому-то нет. Мне нравится.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, thesz, Вы писали:
T>>>>Читай — выражены в виде типов. G>>>Это не единственный способ выражения контрактов.
T>>Ну, вырази контракт "не должно быть deadlock".
E>Можно попросить провести маленький ликбез в порядке просвящения? Вот есть хорошая задача: даны два банковских счета и нужно провести операцию перевода денег с одного на другой. На псевдокоде это выражается приблизительно так: E>
Вот пример блокировки оттуда:
1. Simon sends Phil £20, beginning by executing lock(Simon).
2. Phil sends John £10, beginning by executing lock(Phil).
3. John sends Simon £42, beginning by executing lock(John).
4. Now all three resources are locked—none of the processes can lock the resource associated with the receiver! The system is deadlocked.
E>Как можно описать контракт для типов Account и/или операции transfer, чтобы гарантировать, что операция не будет вести к тупикам?
Упорядочить блокируемые ресурсы.
Simon<Phil<John
E>Если можно на пальцах с применением C/Java- или Pascal-, или Python-онобразного псевдокода. А то у меня от коротких примеров на Haskell крышу сносит.
1. Simon sends Phil £20, beginning by executing lock(Simon).
2. Phil sends John £10, beginning by executing lock(Phil).
3. John sends Simon £42, beginning by executing lock(Simon) (Simon<John).
Теперь Фил пошлёт Джону денежку и разлочится, Семён пошлёт Филу денежку и разлочится и (ура!) Джон пошлёт Саймону денежку.
Основная задача состоит в том, чтобы на уровне типов заставить Account иметь операцию сравнения и заставить lock выполняться сперва над меньшим операндом. И чтобы операция сравнения была представима в виде DAG.
Если мы присобачим к lock операнд lockContext, то мы можем сделать что-то вроде такого:
lock(lockContext : LockContext<Empty>, account : Account<Account_Index>) { обычная блокировка, вернём LockContext<Pair<Account_Index,Empty>> }
lock(lockContext : LockContext<Pair<PrevAcc,Tail>>, account : Acccount<ThisAcc>
-- этого нет в Java, но:
,dummy : TypeLevel_Less(PrevAcc,ThisAcc) := unit -- чтобы не указывать аргументом
-- TypeLevel_Less переписывает пару типов в unit, если первый меньше второго
-- и в ничто (давая ошибку типа) в противном случае
) {
блокировка, вернём LockContext<Pair<ThisAcc,Pair<Account_Index,Empty>>>
}
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
The other point I found interesting was when Gladwell alluded to the fact that most brilliant children don't become "successful" but usually have "happy" lives. He suggests that it is an almost deliberate choice, i.e. because they were brilliant they realized the combination of sacrifices and luck needed to become successful, and determined it just wasn't worth it.
T>)
Угу полно блестящих талантливых людей с не очень высоким IQ
.
Т.е. мок инфраструктуры детектирует дедлок (бросая, к примеру, ексепшн вместо зависания), а мок-аккаунты занимаются тем, что искусственно продляют время транзакции для 100% гарантии наступления дедлока, если он возможен.
Тест тогда запускает две одновременных транзакции transfer(a, b, 100) | transfer (b, a, 100). Приведённый тобой код получит дедлок, после чего у программиста появится повод переписать его вот так:
transfer(from: Account; to: Account; amount: Money) {
var first = Min(from, to);
var second = Max(from, to);
lock(first) {
lock(second) {
a.debit(ammount)
b.credit(ammount)
}
}
}
После этого, очевидно, дедлок возникать перестанет. Заодно тест сможет проверить, что все инварианты корректно выполнены — в частности, вот такой код
transfer(from: Account; to: Account; amount: Money)
{
a.debit(ammount)
b.credit(ammount)
}
дедлока вызывать не будет, но сумма (from.Balance + to.Balance) изменится после отработки теста.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, thesz, Вы писали:
T>Другая разница состоит в необходимости править программу до упора, пока не заработает в случае TyDD. Кому-то это нравится, кому-то нет. Мне нравится.
Еще не стоит забывать что эти методы не является полностью взаимозаменяемыми.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, thesz, Вы писали:
T>>Другая разница состоит в необходимости править программу до упора, пока не заработает в случае TyDD. Кому-то это нравится, кому-то нет. Мне нравится.
FR>Еще не стоит забывать что эти методы не является полностью взаимозаменяемыми.
Да. Тесты при этом уменьшаются до функциональных, приблизительно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)