По-моему - "риторический вопрос"

http://delphi2010.ru/firedac-sqlite-encoding/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Delphi2010ru+%28Delphi+2010.ru%29

 "Во многих СУБД про кодировку строк нужно помнить ещё перед установкой самой СУБД.
Кстати это вот один из злейших недостатков датасетов – если в дизайнере насоздавать поля, а потом в БД чего-то поменять, то синхронизировать это с исходником… мягко говоря неудобно.
Меня вот удивляет, почему ещё никто не предлагает (пусть даже платных) решений-альтернатив датасетов? Или они есть, но малоизвестны, потому-что все привыкли к датасетам?"

По мне, так по-моему - всё объясняется "консерватизмом" и "ленью".

Про TDataSet у меня вообще есть "свой взгляд", но я его пока - "оставлю при себе".

С Леоновым про TDD

-3. Некоторые вещи - РЕАЛЬНО ЖЁСТКО написаны. Не принимайте это лично на свой счёт. Просто "такой стиль".

-2. Тут не БУДЕТ ВООБЩЕ никаких ПРИМЕРОВ кода. Лишь "вода" и "поток сознания". Если понадобятся примеры кода - буду писать их отдельно.

-1. Наверное понадобятся "разъяснения и дополнения". Я - готов к ним.

0. Буду отвечать "в режиме спринта". Вдохнул - начал писать - закончил писать - выдохнул. Может быть где-то напишу откровенный бред, но вы его - корректируйте.

18.12.2013 17:13, Vsevolod Leonov пишет:

Отнеситесь, пожалуйста, с юмором. J

1. Можно в блоге написать что-то вроде "как меня достал Леонов своими тупыми вопросами о тестах. Как можно не понимать простых вещей?"? Раздуем так сказать "КОНФЛИКТ"?

2. Вот смотрите. Есть "банда четырёх", а мы с вами похоже - "два придурка". Один придурок не понимает "зачем нужны тесты", а второй придурок - не понимает - "как можно не понимать "зачем нужны тесты"". В этом ключе и поведём дальнейший разговор. Ок?

3. Отбросим "формальности" и "интеллигентность" (которой у меня в помине не было). Будем "резать правду-матку". Ок?

Test Driven Development или битый небитого везёт

4. Давайте "сразу определимся". Я НЕ ИСПОЛЬЗУЮ TDD в его классическом понимании. Как и не использую UML (про который мы уже говорили и разговор о котором Леонов своей "кармой" прямо скажем "испортил" (не слишком резко?)).

Так вот! ЕЩЁ РАЗ! Для непонятливых.

Я НЕ ИСПОЛЬЗУЮ TDD в его "классическом понимании".

Чтобы потом не говорили "Люлин не читал википедию" (хотя Люлин её конечно читал, но она ему - "нафиг не упала") и не "тыкали носом" во что-то "типа Лармана" (Лармана я кстати - ПЕРЕЧИТАЛ! ОТКРОВЕНИЙ - не нашёл).

Посему!

Ещё раз! Для СОВСЕМ непонятливых.

Я НЕ ИСПОЛЬЗУЮ TDD. Я использую СИНТЕЗ подхода из TDD и "свои собственные мысли".

Я КРИТИЧЕСКИ ОЦЕНИВАЮ мысли умных людей.

И беру из них "то что помогает работе" и выкидываю "то что работе МЕШАЕТ".

И именно этот "синтез" мы далее по тексту будем понимать под "акронимом" TDD.

Ок?

TDD - это попытка поставить всё с ног на голову. В классике инженерного дела сначала создаётся установка/техническая система/машина/агрегат. Конечно, методика испытаний имеется в виду при проектировании… но всё-так, программисты – это какой-то особый вид инженеров? Генетически ущербных? Сами себя таким не считаете?

5. Тут всё зависит от ОПРЕДЕЛЕНИЙ - что "голова", а что "ноги". И как известно - САМЫЙ НАУЧНЫЙ спор это спор о терминах.

6. " Конечно, методика испытаний имеется в виду при проектировании" - ВОТ ИМЕННО - "МЕТОДИКА ИСПЫТАНИЙ". В софтверной инженерии её к сожалению - НЕТ (в ПРОМЫШЛЕННЫХ МАСШТАБАХ).

7. "Генетически ущербных?" - ИМЕННО ТАК. "ОНИ" (мы) почему-то решили, что ЛУЧШЕ ДРУГИХ инженеров, которые например делают велосипеды.

8. " Сами себя таким не считаете?" - СЧИТАЮ. И ИМЕННО поэтому и стремлюсь ВСЕМИ СИЛАМИ стать "ДРУГИМ". Стать ЛУЧШЕ. Не считать себя ИСКЛЮЧЕНИЕМ из ОБЩЕЙ инженерии. "Ах блин Я - ТВОРЕЦ". Нифига не ТВОРЕЦ. Ремесленник! Не более того. И ВСЕ программисты - РЕМЕСЛЕННИКИ (за исключением ЕДИНИЦ).

И это надо ОСОЗНАТЬ, ПОНЯТЬ и СМИРИТЬСЯ с этим.

И стать ИНЖЕНЕРОМ.

С БОЛЬШОЙ БУКВЫ.

А для этого нужны - "допуски, чертежи, и методика испытаний".

TDD - сковывает инициативу разработчика. Уже не сам разработчик контролирует процесс, а задание «валится на него снеговыми комками»? Нет ли психологического дискомфорта? Программист у нас теперь не творец, а бездумная машина реализации придуманного не им функционала?

9. НЕТ! Не сковывает! НАОБОРОТ - позволяет "работать больше" :-) Вместо ОДНОГО класса "приходится" писать ДВА - сам ПРОЕКТНЫЙ класс и ТЕСТ к нему. TDD это как раз для ИНИЦИАТИВНЫХ людей. Которые ЛЮБЯТ свою работу. А БЕЗДЕЛЬНИКИ - нам ни к чему. БЕЗДЕЛЬНИКИ - могут дальше не читать.

10. Ещё как КОНТРОЛЛИРУЕТ! Более чем контроллирует. Сам себя "бьёт по рукам". И заставляет "шевелиться серые клеточки".

11. ДИСКОМФОРТА - НЕТ. Наоборот - есть ощущение СТАБИЛЬНОСТИ (привет Путину) и УВЕРЕННОСТИ в завтрашнем дне.

12. НЕТ! Программист - "ТВОРЕЦ". В смысле - ремесленник :-) Он "творит" - в "ДВА РАЗА БОЛЬШЕ". (Лентяев ведь мы скинули со счетов).

На самом деле - хрен два - "В ДВА РАЗА".

На самом деле - МЕНЬШЕ. Почему? Постараюсь объяснить ниже.

TDD - ставит во главу угла не качество реализации, а сиюминутные фичи. Как можно говорить о качестве кода? Об архитектуре системы? Мы на выходе с точки зрения программного кода получаем «салат оливье» - механическую смесь разных на вкус и цвет мелкопорезанных кусочков? Вы верите, что из винегрета, сложенный большой кучкой может символизировать собой архитектурное совершенно и конструктивное качество?

13. БРЕД!!! Именно КАЧЕСТВО и СТАБИЛЬНОСТЬ (ещё привет Путину) ставится во главу угла.

14. Как говорить о "качестве"? ОЧЕНЬ просто - "есть фича" и "есть тест" проверяющий эту фичу. При таком подходе мы ГАРАНТИРОВАННО получаем качественную (с точки зрения ТЗ) систему.

Что НЕ ПОПАЛО в ТЗ, то и не попало в тесты. Но это уже - "проблема заказчика".

15. Про архитектуру... Давайте подумаем - "а что есть архитектура"? Действительно - что есть архитектура? Про UML ведь мы тут говорить не будем?

Так вот...

Архитектура это не есть "что-то универсальное". И не есть "серебряная пуля".

Я САМ - ХОРОШИЙ АРХИТЕКТОР (к чёрту скромность) и я обладаю УНИКАЛЬНОЙ АССОЦИАТИВНОЙ ПАМЯТЬЮ (опять же - к чёрту скромность). Коллеги - НЕ ДАДУТ СОВРАТЬ. Меня "ночью разбуди" - я расскажу - что и где находится - в каком модуле и не какой СТРОЧКЕ.

Так вот!

При всём при этом даже Я (большая буква - не случайно) - ПОЛНУЮ КАРТИНУ - НИКОГДА не помню.

НИКОГДА!

Архитектура (если не брать UML И "чертежи") - это набор "проектных решений".

Это "калейдоскоп решений и фич". И ТЕСТОВ - "их проверяющих".

Точнее - "матрёшка калейдоскопов".

И все эти калейдоскопы связаны логическими цепочками, которые "можно восстановить в памяти".

Причём тут тесты?

А вот при том - "тесты это ПРИМЕР ИСПОЛЬЗОВАНИЯ конкретного кода и КОНКРЕТНЫХ проектных решений".

Если что-то ЗАБЫВАЮ - мне ДОСТАТОЧНО посмотреть на тест, чтобы это вспомнить.

При этом тесты - БОЛЕЕ стабильны и ИНВАРИАНТНЫ нежели "реальный проектный код". Код перерождается. Эволюционирует. Умирает.

С тестами же это происходит ГОРАЗДО реже.

TDD – некий бич, которым хлещут непокорных IT-рабов? Это что – некий вид «управы» на непокорных, гордо именуемых «разработчиками»? Вы, разрабочтики, не должны думать. Ваша дело – тянуть лямку, выполнять план по валу! Смотри на тесты, данные тобой свыше, и не вздумай проявлять инициативу!

16. Значит так... "Руководству", директорату и (тем более) заказчикам - РЕАЛЬНО НАПЛЕВАТЬ - какие технологии используются (за редкими исключениями).

По большому счёту - НИКОГО НЕ ПАРИТ - какие используются технологии и что там "внутри" делают разработчики. Используют они RUP, TDD/ШмеДД, Agile/СуперАгиле или что-то иное...

НИКОГО НЕ ПАРИТ!!!

Ещё РАЗ - НИКОГО НЕ ПАРИТ.

Всем выше перечисленным "стейкхолдерам" - ВАЖЕН РЕЗУЛЬТАТ. А не ПРОЦЕСС!!!

"Энтропия"!!! Это функция "состояния", а не "процесса".

Никакой здравомыслящий начальник НЕ БУДЕТ "навязывать" TDD.

Это не В ЕГО ИНТЕРЕСАХ.

Ещё раз!

Это не в ЕГО ИНТЕРЕСАХ.

Ему нужен РЕЗУЛЬТАТ. А не "раздражение разработчиков" типа - "вот этот умник опять какие-то навомодные фишки нам навязывает".

УМНЫЙ начальник... Ну РЕАЛЬНО УМНЫЙ - может лишь "сделать так", чтобы разработчики "сами" почувствовали, что "им это надо".

Это - ЕДИНСТВЕННЫЙ путь. Иначе - ТУПИК!

17. НЕТУ "тестов данных свыше". Тесты это "ВНУТРЕННЕЕ" дело разработчиков. И чем лучше тесты и чем их больше, тем разработчики "крепко спят". И тем меньше они "вызываются на ковёр".

Тесты это не средство "управления".

Тесты это средство "спать спокойно". Для РАЗРАБОТЧИКОВ, а не для "начальников".

ЕЩЁ РАЗ - Тесты это средство "спать спокойно". Для РАЗРАБОТЧИКОВ, а не для "начальников".

TDD – попытка некомпетентных и далёких от кодирования людей продвигать свою, чуждую разработчикам идеологию… своё, часто неправильное видение стратегии развития продукта.

18. ЕЩЁ РАЗ!

Для непонятливых.
Тесты НЕ ДИКТУЕТ "директорат", руководство или заказчики.

Тесты - это СРЕДСТВО РАЗРАБОТКИ.

Тесты это "внутренняя кухня" разработчиков и "группы качества".

Все остальные "стейкхолдеры" оперируют ТЗ. Ну или "экранами". Максимум...

19. Тесты и "стратегия развития" - НИКАК не соотносятся.

Допустим, меня обязали следовать технике TDD, хотя, согласитесь, очень многие люди комфортно чувствуют себя без этого. Ну и что это даёт по сравнению с нормальной техникой, когда «запланировали – реализовали – сделали тесты – протестировали»? Просто «красивая сказка» для начальника «мы используем передовые подходы?»

20. ЕЩЁ раз!

"Обязать" использовать тесты - НЕВОЗМОЖНО. Можно лишь только "уговорить".

21. Если кто-то чувствует себя комфортно БЕЗ тестов, то значит, что:
 а. Его проект не такой сложный.
 б. Он Всё тестирует на реальных пользователях. (не повезло им)
 в. Он гений.
 г. Он работает ОДИН.

22. Ещё раз. "Сказки" - НЕТ. "начальству" - ВСЁ РАВНО.
Начальству нужен РЕЗУЛЬТАТ, СРОКИ и КАЧЕСТВО продукта.

Напахал я тестов. Начал под них (скрепя сердце) подгонять функциональный код. Выясняется… потом, что тест придуман неправильно. Я поработал впустую?

23. Не НАДО ничего "НАПАХИВАТЬ".

"Алгоритм" - ПРОСТЕЙШИЙ - читаем ТЗ, и реализуем "фичи".

ОДНА "фича" - ОДИН "тест".

И так - ИТЕРАТИВНО.

Фича - порождает фичи, а фичи порождают тесты.

"Матрёшка".

"Калейдоскоп".

XP!!! Если хотите.

KISS-принцип.

А не бывает такого, что «тесты», которые приобрели вид «жёсткого задания», начали противоречить друг-другу?

24. О! Это мой ЛЮБИМЫЙ вопрос! Это "ГЕНИАЛЬНЫЙ" вопрос.

Только идиот НЕ ПОНИМАЕТ ответа.

Давайте ПОДУМАЕМ!

Что ОЗНАЧАЕТ фраза "тесты начали противоречить друг-друг".

Давайте ВКЛЮЧИМ ИНТЕЛЛЕКТ!

Если тесты "противоречат друг-другу" это означает, что:
 а. ТЗ недостаточно ПРОРАБОТАННО.
 б. ТЗ ПРОТИВОРЕЧИВО.

Тут надо "сказать СПАСИБО тестам" и ВЕРНУТЬСЯ к проработке ТЗ.

TDD – потеря времени. Давайте уж сначала напишем код, а потом будем его тестировать. Любое хождение «задом-наперёд», ненатуральный порядок разработки, даже если не сказывается на качестве, обязательно вызовет «тормоза».

25. Хорошо. Давайте напишем код. Напишем. Покоммитим его в CVS/SVN. И что?

Мы свою работу сделали?

Типа "как повезёт"? Прокатит/не прокатит?

Можно и так.

Только потом тебя "поднимут с постели" и спросят "что за хрень ты тут написал?"

Так?

Можно ведь по-другому - "написать код" и "ПРОВЕРИТЬ его". А как мы его будем проверять?

"Тупым" протыкиванием?

А если для "протыкивания" надо сделать 20-ть шагов? А если 100? А если "данных нет"? А если "смежники не готовы"?

Не лень?

Не проще ли "написать тест" хотя бы для отладки?

С придуманными "из головы" входом и выходом.

По-моему - ПРОЩЕ.

А если тест УЖЕ написан и использовался для ОТЛАДКИ, то почему не включить этот тест в "ночную сборку"?

TDD – способ поставить разработчика в унизительное положение. «Битый небитого везёт». Программист работает «от чувства вины» в перманентном состоянии нереализованности поставленной задачи.

26. НАОБОРОТ!

У программиста всегда есть "реперные точки".

Тут вот я написал тест. Он не проходит.

Тут я реализовал функционал.

Тест стал ПРОХОДИТЬ.

Я всё покоммител в CVS/SVN.

Я свою работу СДЕЛАЛ и "могу спать спокойно".

TDD – нет ли ощущения, что программист всё время решает «обратную задачу»? Или разработчик – двоечник, подгоняющий решение под ответ задачи?

27. А программисты - ВСЕГДА решают "обратную задачу". Ну или "строят коня в вакууме".
28. Нет - НЕ ДВОЕЧНИК. Просто - "обычный человек". Который НЕ МОЖЕТ предусмотреть ВСЁ. Но зато то, что он ПРЕДУСМОТРЕЛ - ГАРАНТИРОВАННО работает.
29. Есть и другие люди. Но они - ГЕНИИ. Их - МАЛО.

TDD – разработка в зазеркалье. Мы выполнили тесты, что не есть гарантия безошибочности. Кто отвечает за качество тестов?

30. Ещё раз!

ТЕСТЫ это не средство "битья по рукам".

ТЕСТЫ это средство - "спать спокойно".

31. ГАРАНТИИ "полной безошибочности" - НЕТ.
Есть лишь гарантия того, что разработчик ПРАВИЛЬНО понял ТЗ и реализовал его так как ПОНЯЛ.

TDD – телега впереди лошади. Лошадь постоянно тыкается мордой «в задний бампер», не видя ничего впереди себя. Как можно говорить о продумывании функционала в целом на уровне архитектуры системы, когда впереди – вдаль до самого горизонта – просто свалка потребностей?

32. Вот тут ОПЯТЬ давайте вернёмся к "самому научному спору".

Давайте "ОПРЕДЕЛИМ ТЕРМИНЫ".

Что есть "телега", а что "лошадь".

Если мы почитаем википедию - мы увидим "полный бред".

И я об этом - ПИСАЛ - http://programmingmindstream.blogspot.ru/2013/11/tdd_28.html

и тут - http://programmingmindstream.blogspot.ru/2013/11/tdd.html

"Как можно тестировать то ЧЕГО НЕТ"?

Я САМ задавался этим вопросом.

Пока не ПОНЯЛ одной ПРОСТОЙ ИСТИНЫ:
"лошадь" - это ТЗ.
"телега" - это КОД.

А что есть ТЕСТЫ?

Тесты это - "оглобли" которыми "лошадь" привязана к "телеге".

Т.е. - ВЕДЁТ - ТЗ, а тесты - "тянут за собой" код. И ПРОВЕРЯЮТ его соответствие ТЗ. И то что "код едет в ту же сторону, что и ТЗ".

Нету ни TestFirst! Ни CodeFirst!

НЕТУ!

Для непонятливых - Нету ни TestFirst! Ни CodeFirst!

ЕСТЬ - ТЗ-First!

ВСЁ - "растёт ногами" из ТЗ и ТЕСТЫ и код и АРХИТЕКТУРА.

И ПОТОМ - ArchitecrureFirst!

Т.е. цепочка разработки выглядит так:
 ТЗ -> Набросок архитектуры -> Тест -> Код

А дальше возможны все разные варианты:
 ТЗ -> Набросок архитектуры -> Тест -> Код -> Тест -> Код
 ТЗ -> Набросок архитектуры -> Тест -> Код -> Архитектура -> Тест -> Код
 ТЗ -> Набросок архитектуры -> Тест -> Код -> Архитектура -> Тест -> Код -> ТЗ -> Архитектура -> Тест -> Код

и т.д. и т.п.

First - это - ТЗ и набросок архитектуры - дальше начинается - "итерационная разработка".

И что - особенно ВКУСНО - это то, что как только мы написали тест - нам НЕ НАДО думать - "а где проверять работоспособность нашего класса".

Мы УЖЕ настроили всю инфраструктуру для его тестирования и проверки.

ИМЕННО в этом и заключается слово Driven в TDD.

Ладно, есть на свете «извращенцы». Тогда хоть как можно облегчить страдания? Какой правильный процесс при этом?

33. Ну я - "извращенец". И ещё ещё как минимум - 6-ть человек.
34. Процесс я описал выше.

Повторю для "идиотов":

Т.е. цепочка разработки выглядит так:
 ТЗ -> Набросок архитектуры -> Тест -> Код

А дальше возможны все разные варианты:
 ТЗ -> Набросок архитектуры -> Тест -> Код -> Тест -> Код
 ТЗ -> Набросок архитектуры -> Тест -> Код -> Архитектура -> Тест -> Код
 ТЗ -> Набросок архитектуры -> Тест -> Код -> Архитектура -> Тест -> Код -> ТЗ -> Архитектура -> Тест -> Код

А какой инструментарий? Как «впрячь коня (упрямый пони на коротких ножках) и трепетную лань (мысль разработчика)?

35. Значит про "мысль". С РАЗРАБОТЧИКОМ - надо "РАБОТАТЬ". Ходить вместе курить. Поить пивом (шучу). Уговаривать. Развлекать.

Сделать так, чтобы ОН ТЕБЕ ПОВЕРИЛ.

И чтобы считал ТВОИ мысли СВОИМИ (привет Карнеги).

По-другому - НИКАК.

ЗАСТАВИТЬ - НЕЛЬЗЯ.

Как и НЕЛЬЗЯ ЗАСТАВИТЬ "писать хороший код".

Можно подарить человеку книгу Мак-Конела на день Рождения. Но НЕ БОЛЕЕ ТОГО!

НИКАКИЕ АДМИНИСТРАТИВНЫЕ меры - НЕ ПОМОГУТ. Вызовут лишь - озлобление.

Я это прошёл и НЕ РАЗ.

36. Инструментарий.

а. DUnit.
б. Доработки к DUnit - http://18delphi.blogspot.ru/2013/03/dunit.html
в. Confluence - http://ru.wikipedia.org/wiki/Confluence
г. САМОПИСНЫЙ аналог JIRA (http://ru.wikipedia.org/wiki/Jira). В ту пору JIRA была ещё "сыра" поэтому мы её не взяли. СЕЙЧАС - я думаю - взяли бы её.
д. Скриповая машина - http://18delphi.blogspot.ru/2013/11/gui.html
е. FishEye (https://www.atlassian.com/software/fisheye/overview).
ё. Доработки к Confluence и FishEye позволяющие отслеживать связь коммитов, изменений кода и строящие привязку КОНКРЕТНЫХ изменений кода к КОНКРЕТНЫМ задачам (если я получу разрешение руководства - опубликуем скриншоты). Я бы на месте нашего руководства давно бы продавал бы это как КОММЕРЧЕСКИЙ продукт.
ж. Интеграция UML и Confluence.

В каком виде и кто создает тесты? А если «роль» создателя тестов не предполагает знание программирования?

37. Тесты создают разработчики. Если речь идёт о новой функциональности.

Или тестировщики. Если речь идёт об ошибках.

И ЧАЩЕ всего - тестировщики пишут ошибку и СРАЗУ пишут к ней тест.

Тут кстати надо понимать ОДНУ ПРОСТУЮ вещь - ТЗ и ОШИБКИ в общем-то ничем НЕ ОТЛИЧАЮТСЯ друг от друга принципиально. Только лишь "зоной ответственности".

38. "А если «роль» создателя тестов не предполагает знание программирования?" - на BDD или Fit-таблицы - мы пока не "замахивались", но мы РАБОТАЕМ над этим.

TDD – это наше «всё» или Вы всё-таки признаёте ограниченность данной техники?

39. "Разруха она в головах, а не в писсуарах".

НЕТУ "ограниченности".

Есть "нежелание применять".

Или "банальная лень".

Ко всем ли системам применима техника TDD? Есть «особые случаи» или «другие подходы»?

40. НЕТ! Нету "особых случаев".

Есть что-то "что можно выкинуть", есть что-то "что можно привнести".

Но в ЦЕЛОМ - TDD - ОСТАЁТСЯ. И ГАРАНТИРУЕТ "спокойный сон".

Что привело Вас к TDD?

41. Я писал об этом тут - http://18delphi.blogspot.ru/2013/03/blog-post.html

И тут - http://18delphi.blogspot.ru/2013/03/tdd-c.html

Что по-Вашему может быть лучше, чем TDD?

42. BDD ;-) Роман Янковский "над ним работает" :-) Ссылка - http://roman.yankovsky.me/?p=1258

Ну и Fit-таблицы. Ссылки к сожалению - найти не могу...

Offtopic. Offtopic. Вот - ДА!

https://www.facebook.com/lulinalex/posts/645080808892864?notif_t=like

Написать про Dependency Injection

P.P.P.P.S. Тут один хороший человек подсказал, что эта тема СИЛЬНО связана с Dependency Injection (http://ru.wikipedia.org/wiki/Dependency_Injection) и ссылку дал - http://docs.jboss.org/weld/reference/1.0.0/en-US/html/

Я эту тему ОБЯЗАТЕЛЬНО постараюсь раскрыть.

Offtopic. Offtopic. Моё ворчание про generic TDictionary от Borland/Embarcadero

Моё ворчание про generic TDictionary от Borland/Embarcadero:

Странная вещь всё-таки. Смешали концепцию полиморфных контейнеров с Comparer'ом etc и концепцию шаблоного контейнера в стиле STL.

Я бы так не стал делать.

Я бы разрулил бы всё это через правильное наследование.

Ну это не к тому, что я кого-то "ругаю". Просто "я бы так не стал делать".

Я бы скажем сделал бы "для начала" так - TCustomDictionary и двух наследников TSTLLikeDictionary и TComparatorSetableDictionary.

Offtopic. Смотрю статистику посещений

Смотрю статистику посещений.

Вот этого - http://18delphi.blogspot.ru/

Люди стали "правильные статьи читать".

1. Абстрактные контейнеры.
2. Инкапсуляция работы с памятью.
3. Подсчёт ссылок.
4. DUnit.

Offtopic. Offtopic. Использование UML. Ларман застрелился бы...

Использование UML. Ларман застрелился бы...

Ссылка. Как пишут числа Фиббоначи на разных языках

http://www.willa.me/2013/11/the-six-most-common-species-of-code.html

Ссылка. "Почему тестирование — это тупо и скучно?"

Почему тестирование — это тупо и скучно? :-)

http://habrahabr.ru/post/106257/

ОЧЕНЬ интересно написано. По-моему...

Понравился визуализатор

http://kcachegrind.sourceforge.net/html/Home.html - понравился визуализатор.

Написать про цепочки EVD-фильтров

Разговаривал сегодня с коллегой в курилке.

И вот ещё какая тема возникла - "Написать про цепочки EVD-фильтров".

Это "типа SAX", только "местного разлива".

... to be continued ...

Offtopic. Offtopic. Про "звёзд" и "работодателей"

Вот Джоэл пишет - "постарайтесь привлекать в свою команду звёзд".

А по-факту - я очередной раз убедился, что про "звёзд" нередко говорят, что-то вроде - "overskilled".

Что я ещё хочу сказать о TDD (не закончено)

Что я ещё хочу сказать о TDD

Предыдущая серия была тут - http://programmingmindstream.blogspot.ru/2013/11/tdd.html

Многие люди с которыми я общался насчёт тестов вообще и TDD в частности "разбивались" о следующее препятствие:

TestFirst. TestDriven.

Я не хочу "спорить", а тем более опровергать или критиковать никого из уважаемых "теоретиков TDD". 

Я лишь хочу описать свою трактовку. Ну или - как я это "для себя" понял.

Об асинхронности и модальности в GUI тестах

Об асинхронности и модальности в GUI тестах

О тестах GUI я писал тут - http://18delphi.blogspot.ru/2013/11/gui.html ну и "в последующих сериях".

Сегодня я размышлял над одной хорошей заметкой моего товарища по цеху - Романа Янковского.

О Awaitable-значениях (http://roman.yankovsky.me/?p=1100).

И неожиданно понял - что ещё я хочу сказать о GUI-тестировании.

Есть два момента с которыми рано или поздно сталкиваются GUI-тестировщики. Когда система входит в такое состояние, когда она блокирует управление и крутит какой-то "внутренний цикл".

А именно:

1. Например показ контекстного меню или что-то подобное.
2. Показ модального диалога и ожидание ввода пользователя.

И это далеко не самая простая проблема.

Ведь код теста - "замораживается" и система "ждёт ввода от пользователя" и тесты на это повлиять никак уже не могут.

Им банально - не отдаётся управление. И они не могут продолжать свою работу.

А ведь - они автоматические и никакой пользователь им не поможет.

Что же делать?

Не перестаю восхищаться библиотекой STL

Не перестаю восхищаться библиотекой STL.

Сегодня правил одну уж очень заковыристую ошибку со сложными структурами данных, так в итоге она крайне элегантно разрешилась при помощи рекурсивных алгоритмов. Я даже сначла сам не понял - "что именно я сделал".

Код "реальной" скриптовой машины

Код "реальной" скриптовой машины.

Вот тут - http://18delphi.blogspot.ru/2013/11/gui-back-to-basics_22.html я писал про устройство скриптовой машины.

А вот тут - https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/ScriptEngine/ я решил выложить код "реальной" скриптовой машины.

Он - НЕ скомпилируется. Но думаю, что ОСОБЕННО пытливым читателям - будет интересен.

Ссылка. "Декорирование элементов перечисления"

Ссылка. "Декорирование элементов перечисления"

Прочитал тут ссылку:

http://blogs.embarcadero.com/nikolay/2013/11/25/scopedenumeration/

Прикольно. В плане "синтаксического сахара".

Непонятно только - зачем понадобился helper. Почему просто определение констант не подошло?

Да и ничего "изящного" - я не вижу. Я РЕАЛЬНО не понимаю ЧЕМ - TMyType.Three СИЛЬНО лучше, чем mtThree.

РЕАЛЬНО не понимаю. Может быть мне дураку кто-нибудь объяснит?

Нет! ВОЗМОЖНОСТЬ - это - ХОРОШО, но это не значит, что надо "бросаться пользоваться этой возможностью".

А ещё можно всё то же самое с модели сгенерировать. Один раз поправив шаблоны генерации. 

Заметки о тестировании №2

Предыдущая серия "потока сознания была тут" - http://programmingmindstream.blogspot.ru/2013/11/blog-post.html

Продолжу.

Пока не забыл.

Опять же о "линейности" и "читаемости человеком".

Пусть нам в каком-то тесте надо поработать с состоянием системы с пользовательской настройкой отличной от умолчания.

Первое что приходит на ум это примерно следующее:

var
 SomeSettingValue : Value;
...
 SomeSettingValue := System.GetValue('SomeSetting');
 DoOurWork;
 System.SetValue('SomeSetting', SomeSettingValue );

- ну что сказать? А если тест упадёт? Всё? Система окажется в нестабильном состоянии? Ну "решение на поверхности" такое:

var
 SomeSettingValue : Value;
...
 SomeSettingValue := System.GetValue('SomeSetting');
 try
  System.SetValue('SomeSetting', SomeNewSettingValue);
  DoOurWork;
 finally
  System.SetValue('SomeSetting', SomeSettingValue );
 end;

- оно конечно лучше.

Но по-моему это то самый случай, когда "за деревьями скрывается лес".

Все эти try..finally явно не повышают читабельность.

Для человека, который должен мочь "читать тест" и "воспринимать его как тест-кейс".

"Хорошее" решение, как мне кажется выглядит примерно так:

 TemporaryChangedSystemStateFor('SomeSettingValue', SomeNewSettingValue, DoOurWork);

Ну или "по-русски":

 "Для шрифта системы в {(20px)}" "Построить предварительный просмотр и сравнить с эталоном" 

Опять же - разница вроде бы невелика. Тонкая грань. Вкусовщина.

Но! С одной стороны мы обеспечиваем стабильность автоматических тестов, а с другой стороны мы не перегружаем человека читающего это лишней информацией.

Если человек читает первоначальный вариант и выполняет тест, то он вроде бы как обязан - вернуть все настройки в исходное состояние.

А если он руками дальше не будет ничего тестировать? Зачем ему это?

А если будет, то там есть - "подсказка".

Но именно - подсказка, а не побуждение к действию.

Ну вот как-то так мне кажется.

Опять же - ни на чём - не настаиваю.

Заметки о тестировании

Ещё раз хочу повторить вот что:

1. тест должен быть линейным
2. похожим на тест-кейс
3. читаться человеком
4. оперировать терминами предметной области

К чему это я?

Я сегодня просматривал код. Много разного кода. И некоторые вещи заставили меня задуматься о том, что есть вещи которые видимо стоит повторять неоднократно.

Что я хотел сказать о TDD, но всё как-то недосуг. "Дорога в тысячу ли начинается с одного шага"

Моё знакомство с "промышленным тестированием" было описано тут - http://18delphi.blogspot.ru/2013/03/blog-post.html

И с тех пор я ничего лучшего не написал.

Но это было далеко не TDD.

И не "тестирование в широком смысле этого слова".