Уважаемые коллеги, хочу представить вам систему тестирования Delphi приложений TestMe-ON.
Сайт: testme-on.com

Продукт посвящается тем:
* кто хотел бы тестировать, но не знает как
* кто считает что тестирование усложняет/ограничивает разработку
* кто убежден, что время затраченное на кодирование тестов равно или больше самой разработки
* что тестировщики и разработчики это разная каста
* кто уже тестирует, но его что то не устраивает
* кто хочет иметь одну большую кнопку, которая решит все его проблемы :)

Преамбула:
Мы все хотим создавать быстро, качественные приложения и комплекс TestMe-ON (он будет расширяться) поможет разработчикам повысить качество разработки, а главное ее скорость, так как поиск ошибки занимает намного больше времени, чем разработка.
Те кто ведет проект по нескольку лет со мной согласятся, когда меняются требования, логика, условия работы ПО, или кода проект ведут несколько разработчиков и изменение требований одного модуля, затрагивает другие модули, других разработчиков. Ошибок не было и вдруг появились. Так не должно быть, но так бывает. Причин много. Логика не идеальная,заказчик решает изменить ключевую логику, что приведет к изменению архитектуры. В SVN коллега закоммитил старый исходник (буквально сегодня это сделал, о чем он думал, куда смотрел?).
Ошибки, ошибки, ошибки и кому их искать? Кому править?
Нам разработчикам!

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

Время - это единственный критерий, что заставило меня заняться тестированием.
Время - это единственный критерий который учитывался при разработке TestMe-ON.Code.
Вывод: Сделать скоростное написание тестов простым и понятным способом.

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

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

TestMe-ON.Code очень удобная система тестирования кода, для меня, и я надеюсь, что мой подход к тестированию будет удобен и для вас.

Документация, примеры, видео на сайте testme-on.com

Для оперативной связи используйте:
почту: support@testme-on.com
форум поддержки на сайте: testme-on.com
Viber & WhatsApp +7-9999-82-50-16 (телефон отключен)

Гаджимурадов РустамКакая лицензия у продукта?
Не знаю пока Рустам.
Продуктом пока сложно это назвать.
Из запланировано 10% всего выложено.
Будут ли пользоваться в своей работе коллеги TestMe? Не знаю.
По лицензии, DevExpress, EhLib, FastReport, IBExpert стартовали бесплатными.
Из них EhLib наверно дольше всех продержался бесплатным.
Как поступить, не знаю. В раздумьях пока.
Можем в личке пообщаться.

makhaonБезотносительно самой системы. Лучше таблицу выполнить наоборот:

Спасибо изменил.

L_argoСовершенно не представляю, как это может пригодиться.

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

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

Гаджимурадов РустамНу так Вы подумайте, и решите, да поскорее.
Отписался на почту.

white_niggerКакие преимущества по сравнению с DUnit/DUnitX поставляемыми с делфи?
Отличие принципиальное.
Это скорость создание тестов и максимальное упрощение.
Если Вас интересует тестирование, попробуйте сделать тест функции DIVIDE, которая в примере на странице "Быстрый старт" с помощью DUnit/DUnitX.
Для меня очень неудобно держать код тестирования в отдельном модуле.
Постоянно какие то правки, изменение функционала, в DUnit/DUnitX приходится поддерживать актуальность в 2-х модулях, для меня показалось это очень затратным по времени и сложным.

Замечания по лицензии поправлю.

Гаджимурадов Рустам строгое ограничение, что тесты должны быть в тех же модулях, что и сам код ?
white_niggerВшивать тестируемый код в сырцы - утопия для серьезного проекта
Ограничений где держать тесты никаких нет, можно во внешних файлах.
Версий для внешних файлов две. Файлы PAS и файлы INC.

Файлы PAS.
Плюсы: тестовые код не хранится с исходниками. Это единственный плюс который я вижу.
Минусы:
Тестировать можно только паблик классы и паблик методы, c переменными.
Для приватных и протектед методов и переменных придется использовать хак классы. Что с одной стороны усложняет написание тестов, с другой стороны заставляет держать в актуальности 2 версии класса, класс оригинала и класс хака, а это опять сказывается на снижение производительности и все скатывается в работу над тестами, ради самих тестов.
Но самый главный минус в другом, это сложность тестирования классов и переменных после implementation.
Желание делать тест классов и переменных которые находятся после implementation , заставляет переходить к написанию обертки над компилятором, с анализом бинарного кода и MAP файлов. Программа тестов становится даже не на один порядок сложнее, так как надо учитывать все компиляторы и прогонять тесты работоспособности по ним всем.
Поэтому если кому то нужно держать тесты в отдельных юнитах, держите, но это накладывает ограничение на грубину тестов.

Файлы INC.
Плюсы: тестовые код не хранится с исходниками. Это тоже единственный плюс который я вижу. но есть еще плюс к PAS файлам, что можно тестировать классы и переменные после implementation
Минусы: Я раньше использовал Include, но с моментом значительного роста тестов стало очень накладно держать все в актуальном состоянии попутно кидая их в SVN. Сложность работы с Include файлами увеличивается прямо пропорционально количеству модулей тестов и наступает момент, когда это все осточертеет и тестирование с отладкой начинает превращаться в муку. Еще ведь не удобно входить в этот Include из IDE, единственный способ это руками открывать файлы, ну и при отладке тестов были проблемы. Отладчик никак не хотел заходить в Include исходники.


white_niggerPS: на сайте надо поправить некоторые строки и видео, типа почему "'2 div 2=4'); // True result"
Спасибо увидел, результат теста 1, а в комментарий 4.