R>>Слишком сложно сделано, типичный программистский проект для того чтобы можно было усложнить написание программ, а не облегчить.
G>Найдите и покажите продукт который бы решал эту проблему проще и быстрее, чем TestCode.

Я за вас не должен решать ваши проблемы. Лично у меня своя библиотека тестирования. Несколько десятков строк кода в одном файле.
Решает все задачи, какие мне нужны. И это благодаря препроцессору C++. А на Delphi, когда я на нем еще писал,
использовался элементарный if. Без надобности платить неизвезтно за что неизвестно кому. И это еще в те годы (начало 2000х),
когда юнит тестирование еще не было настолько модным, насколько оно стало.

G>Если мы хотим тестировать код, то тесты все равно лучше писать, чем не писать.

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

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

G>Но с помощью TestCode, это можно сделать с самыми минимальными усилиями и с максимальной скоростью покрытия тестами функционала.

Рекламное бла-бла-бла ни о чем. Пытаетесь потенциального покупателя заболтать? Нет доказательств. Это выглядит как рекламное вранье.
Все, что вы пишите пользователям, должно быть не просто правдой, но и иметь доказательства, а это факты, примеры, истории из жизни,
реальные люди, кто может посоветовать, цифры и прочее. Если ничего такого нет, ваш продукт не готов к продаже.
И позвольте пользоватям самим решать что хорошо а что плохо. Так вы не попадете в дурацкое положение, когда навязываете
пользователю мнение, противоположное его впечатлениям. Лучше давать пользователю факты, на основе которых он сам вам скажет, что
у вас отличный продукт.

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

Ну и что? Я однажды делал для себя продукт, где тоже перерабатывал код, учитывал пожелания. А потом посмотрел более внимательно
и понял, что писал полную хрень. В итоге все переделал и все упростилось в разы, стало простым, ясным и с тех пор ни за что на свете
не вернусь к тому ужасу, какой я считал одним из лучших своих продуктов, который «прошел через годы использования и показал себя с наилучшей
стороны» и т.п. бла-бла-бла, в какую я верил. Сейчас даже смешно вспоминать, какую каку я написал тогда и использовал.

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

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

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

R>>Переусложнение сквозит во всем, начиная с количества юнитов
G>Это реальная проблема для программиста с дефайном подключить юниты?

Это реальная проблема — усложнение. Это причина номер один, почему программисты не хотят писать тесты.
Написание даже простого теста само по себе потребует столько усилий, что даже не тянет смотреть то, где требуется даже лишние 10 букв напечатать.

G>Четыре действия это долго?
G>1.Выделить на сайте код
G>2.Скопировать в буфер
G>3.Щелкнуть мышкой куда вставить юниты
G>4.Вставить из буфера код.
G>Это долго?

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

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

Вот как я пишу тесты на C++:

1. Копирую в проект один хидер.
2. Подключаю его запуск в main(), дописывая одну строчку вызова прогонов тестов.
3. В любом новом cpp файле я вписываю:
#include "test.hpp"
TEST() {
}
4. В этом месте пишу любой код с проверкой по assert()
5. Запускаю экзешник и вижу результаты.
6. Если нужно добавить новый тест, снова пишу
TEST() {
}
7. Если нужно просто поэксприментировать с кодом, я просто пишу
TEST() {
}
и вписываю сюда любые эксперименты, а потом стираю или убираю этот участок.
7. Если тесты больше не нужны, убираю из main() вызов тест-функции.

Все. Элементарно, бесплатно, просто.

R>>Для начала нужно осознать, почему программисты не хотят писать тесты.
G>1. Не знают как.
G>2. Существующие методы тестирования не помогают, а усложняют разработку.

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

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

Подобные изъяны есть в любом старом фреймворке тестирования первых поколений, каких пруд пруди.
Весь интернет завален подобным и бесплатно. Вы добавили еще один, да еще и платно.

G> Когда в приказном порядке наша группа стала делать тесты (WhileBox,BlackBox), что как минимум на 40% увеличило время разработки, а реальное время стало в 2 раза больше. То есть с тестами, которые должны помогать, мы стали срывать сроки. На уши встали все.
G>Оставили тогда только нагрузочное тестирование.
G>Ведь этот продукт родился далеко не от хорошей жизни.
G>Все понимают, что тестировать надо, но нужно что бы это было удобным, с равномерным покрытием и что самое важное это должно делаться очень быстро.
G>Но с тестами был сделан шаг дальше.Теперь тесты, это штатный инструмент отладки.
G>Сейчас при разработке TestCode:
G> Первый пункт — это инструмент отладки
G> Второй пункт — проверка функционала при изменениях проекта.

Типичная история. Но успех не в вашем продукте, а в том, что программистов перестали кошмарить приказами писать тесты.

G>После этого появились много плюсов, один из которых, при групповой разработке, разбираться в ошибках приходится тому, кто их создал, а не автор модуля.
G> Если автор модуля не прав, добавляются тестовые данные, создающие ошибку и все, человек исправляет свои косяки, но часто бывает, что ошибки бывают косвенные, ошибка в модуле А, но причина не в модуле А, а в модуле С.
G> Такие тесты очень экономят время, лично я прям в восторге от этого.

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

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

G>Другой плюс, про который совсем не думали, это время обучения персонала. В несколько раз специалист "входит в проект" быстрее, если код с тестами.
G>Вот как то так.

Не доказали ценность вашего продукта.

Самозабан