>> да и еще такой сложный
G>Сложный?
G>На мой взгляд, система контроля версии (trunk,branches,tags,hotfix) на много сложнее.

Лучше сравнивать инструменты одного предназначаения. Это работает на ваш продукт.
А сравнение с другими сущностями вносит подозрение. Вы же не систему контроля версий предлагаете.

G>Можно узнать в чем сложность?
G>Все что надо это:
G>1. Зарегистрировать класс
G>2. Зарегистрировать метод
G>3. Зарегистрировать входные данные и результат
G>4. Вызвать тестируемый метод
G>- это минимальный набор

В каждой из этих частей, если это ключевая идея вашего продукта, нужно сделать все возможное, чтобы это
выглядело удобней для программиста. Даже если у вас очень сложные внутренности, эти сложности лучше не показывать
пользователю, а наоборот, спрятать это подальше. Смысл в том, что программист в принципе своей профессии вынужден
одновременно удерживать в памяти огромное количество фактов. Это чрезвычайно трудная задача, и она является
основной причиной багов.

А теперь посмотрите на свой сайт. Вы туда выложили чуть ли не все внутренности и кучу разных сущностей,
например, зачем-то еще какой-то калькулятор. На главной странице находится переусложненный скриншот,
демонстрирующий какие-то непонятные возможности. Даже дерево тестов у вас усложнено дополнительным уровнем иерархии.
И так в каждой сущности, куда не ткни — везде торчат уши сложности.

В Delphi достаточно сложная объектная модель с ее событиями, свойствами и другими элементами. Работа с объектами
требует многословности в коде. Т.е. писать тесты для Delphi трудней, чем это может быть на других языках.
Из всего что есть в языке, я бы на вашем месте выбрал только то, что бы упрощало
создание теста, без необходимости написания рутинных обязательных действий.

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

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

А вот то, что вы считаете простым, очень сложно:
http://testmecode.com/doku.php/ru/sampl_code_faststart

Мне очень не хочется тратить время на детальную порку, но пройдусь все же.

«Определите в опциях «Conditionals Define» — TESTME для тестирования и удалите когда захотите отключить код тестирования в приложении.»

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

«Подключить в uses модули TestMe»

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

«Определить 2 метода для регистрации и тестирования класса»

В примере указаны шесть строчек кода !!!!
Из них названия методов трудны для запоминания, а параметры и вовсе запомнить невозможно.
Все это можно было упростить, используя один метод по типу RegisterTest(), а в идеале Test().
Идея в уменьшении сложности, спрятав сложности подальше от программиста.

«Определить и закодировать методы которые будете тестировать»

Уже в самом описании непонятно, что имеете ввиду. Мне пришлось секунд 10 соображать, что это.
Можно же было написать проще понятней, например, «будем тестировать, например, функцию Divide(), вот ее код:».
А так, мне показалось, что нужно обязательно как-то определеть и кодировать какие-то методы, каких у меня пока нет, а как это делать, не ясно.

«Ограничим блок DEFINE для тестирования»

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

«Опишем методы которые будем тестировать, оставив методы пустыми»

Это все можно было бы указать выше, в инструкции про два метода для регистрации.
Потому что очевидно, что в Delphi это нужно делать обязательно потому как таков язык. Более того, на самом деле ничего писать не нужно,
достаточно знать клавиатурное сочетание, по какому среда Delphi сама создаст все нужные методы.

«Зарегистрируем модуль который будем тестировать в блоке initialization»

И ниже я вижу 8 сточек кода, какие невозможно запомнить. Там есть условное выражение, инициализация модуля, условная компиляция,
присвание, несколько неочевидных параметров, два текстовых параметра. Нахрена столько сложностей?!
Неужели от всего этого нельзя было обойтись?


«Зарегистрируем методы которые будем тестировать»

И снова ваш любимый гигантизм: 14 строк кода, накие не только трудно запомнить, трудно понять, что там делается.
Какие-то непонятные массивы с загадочными цифрами, два условия, какие-то непонятные константы, несколько загадочных текстовых параметров и комментарии, которые непонятно что комментируют и что означают.

Это вообще ни в какие ворота не лезет.

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

«Кодируем сам тест»

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

А конструкция if (чтото) then return(Ok) else return(Error) и вовсе falspalm.

Дополнительные трудности возврата обычно скрываются обычно таким паттерном в псевдокоде:

method(lib) {

// если все плохо, регистрируем
if (плохо) lib.ploho_tak()
if (плохо) lib.ploho_inache()

// если все хорошо, ничего делать не надо.

}

Минимально для юнит тестирования достаточно написания вызова тестируемой функции со сравнением результата.
Есть множество подходов того, как это сделать, чтобы передать результаты в фреймворк тестирования,
вы, похоже, выбрали один из самых сложных вариантов. Ради чего все так городить?

procedure TestDiv()
begin
if Divide(6,3) <> 2 then Test.Failed(возможные пояснения);
end;

Все. Одна строчка кода. Больше ничего не надо. Все остальное должны делать ваши кишки. Если же вам нужно зарегистрировать методы тестирования,
то лучшим вариантом было бы не городить кучу кода, а прямо вызвать нужные функции, передав их адрес в ваш фреймворк, а в идеале, все можно было бы сделать так:

procedure Tests()
begin
TestDiv();
TestMul();
end;

procedure TestDiv()
begin
Test.Register('Деление');
if Divide(6,3) <> 2 then Test.Failed('Деление не прошло');
Test.Register('Умножение');
if Multiply(6,3) <> 18 then Test.Failed('Умножение не прошло');
end;

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

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

R>>Решает все задачи, какие мне нужны. И это благодаря препроцессору C++. А на Delphi, когда я на нем еще писал,
R>>использовался элементарный if.
G>Препроцессор действительно хорошая штука, но "элементарный if" для тестов?

if — это конструкция языка, какая идеально подходит для тестирования. Потому что тестирование — это сравнение, то что делает if.
Все что нужно дополнительно — это прогон тестов и регистрация состояний. То чем занимается фреймворк тестирования. По условию if
достаточно передать фреймворку какой-то сигнал, чтобы он сделал все что нужно.

G>М-м-м-м, если программист один, то может писать как он хочет, если в группе, то ата-та по попе ему обеспечено.
G>Как минимум нужно Define использовать.

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

G>Возьмите класс на 5-10 методов, сделайте тест, что бы компилировался, дайте ссылку или пошлите по почте, давайте сравним.

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

R>>Потому что смотрите замыленными глазами, а нужно смотреть глазами тех, кто никогда не видел ваш продукт и не связан с вами обязательствами
G>Возможно, и тут очень важна обратная связь.

R>>Напишите полностью все шаги и увидите, что у вас лишних шагов настолько много, что пропадает желение даже близко начинать писать тесты.

G>Сейчас полноценное написание теста это
...
G>Эксперт сейчас не запускается так как нужен фидбек и возможно, еще что то поменяется.

Учитывая то что вы увидел и написал выше, ваш «эксперт» будет сам городить говнокод.
Но разбираться в этом говнокоде все-равно придется программисту. И вписывать в него свой код. Фу.. страшно представить, как вас будут материть те, кому
придется в этих дебрях кода помещать свой код.

Так что лучше делать не так, чтобы пользоваться без экспертов было невозможно, а чтобы надобность в экспертах была ненужна вообще!
В этом и суть того что я вам сообщаю — у вас переусложненное решение. Это же рынок, программисты нуждаются в упрощении своего труда,
а не в усложнении.

G>Мне это очень интересно.

А мне нет. У вас коммерческий интерес, а я за идею вам помогаю на форуме. Понимаете?

R>>потом проделывать десятки шагов, чтобы только начать.
G>Пока всего 6

См. выше про ваши шаги.

R>>какие ждут пользователю, когда код придется модифицировать и все тесты, какие он писал ранее,
G>Вообще то этом и заключается тестирование!
G>Что бы при изменении спецификации старые тесты или проходили или должны быть модифицированы. Как по другому проверить правильность кода? Верить разработчику "на слово" не видя тесты?

Это выполняется как раз принципом минимальности лишнего кода. Чтобы при модификации не пришлось в куче мест переписывать по несколько раз.
В идеале меняется только то место, где есть вызов изменившихся мест. У вас же придется менять в нескольких местах, причем вы там нагородили много
всего такого, что усложнит это.

R>>придется переделывать, мучаясь с проблемой железо-бетонной связностью с кодом тестирования, где придется
R>>переделывать каждый из тестов. А потом, когда вдруг захочется писать версию 2 проекта,

R>>А вы даже советуете жестко завязывать тесты с кодом бизнес-логики проекта, считая это плюсом.
R>>На деле это такой гемор, в какой не захочет вляпаться опытный программист, какой уже ранее делал так.
G>Тесты делают на функционал, код должен работать так, как описано в спецификации.
G>Если меняется спецификация и логика, то должны быть изменены и тесты.
G>А как по другому полноценно проверить код без тестов?

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

Дешевая модификация — это минимум связности, минимум кода обвязки, миксимум связных вещей в одной единице, чтобы при модификации
тут же изменить и связные вещи.

G>Программист все равно подготавливает данные, с ними отлаживает функционал, а если пришел тикет об ошибке, то программист так же тестирует — отлаживает свой код, с тестовыми данными, только ручками в отладчике.
G>Я сейчас просто не представляю, как можно было по другому вести разработку.

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

Хотя сейчас прям бери и делай вместо вас такой продукт!

Я ж вам не просто порку делаю, а даю ту самую обратную связь, какую вы возможно будете получать через много месяцев уже после того как все менять будет уже поздно.

R>>Весь интернет завален подобным и бесплатно. Вы добавили еще один, да еще и платно.
G>Да, платно. Так как на разработку нужно время, а время это деньги.

Если бесплатное обладает теми же свойствами, то выбор будет не в вашу сторону.

G>И хорошие специалисты стоят хороших денег.
G>И средства пойдут в первую очередь на дальнейшую разработку продукта.

Себя хвалить успеете еще)

R>>Чтобы выделиться на рынке, вы должны выделиться. А у вас еще один из многих переусложненный фреймворк.
G>Я с этим категорически не согласен.
G>Покажите более простой инструмент тестирования.

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

R>>Не доказали ценность вашего продукта.
G>Возможно, но я очень хочу это сделать.

Предлагаю тогда поиграть в игру. Представьте что вы инопланетянин, впервые на планете земля.
И вы заходите к себе на сайт. И понеслось! Все что вам покажется странным и необычным с точки зрения инопланетянина — записывайте!
Такой прием поможет немного убрать замыленный взгляд на свое детище.

Самозабан