Здравствуйте, rean, Вы писали:
> да и еще такой сложный
Сложный?
На мой взгляд, система контроля версии (trunk,branches,tags,hotfix) на много сложнее.
Можно узнать в чем сложность?
Все что надо это:
1. Зарегистрировать класс
2. Зарегистрировать метод
3. Зарегистрировать входные данные и результат
4. Вызвать тестируемый метод
— это минимальный набор
R>Решает все задачи, какие мне нужны. И это благодаря препроцессору C++. А на Delphi, когда я на нем еще писал,
R>использовался элементарный if.
Препроцессор действительно хорошая штука, но "элементарный if" для тестов?
М-м-м-м, если программист один, то может писать как он хочет, если в группе, то ата-та по попе ему обеспечено.
Как минимум нужно Define использовать.
R>Без надобности платить неизвезтно за что неизвестно кому.
Можно и бесплатно, я писал что 100 параметров это на средний проект хватит.
G>>Но с помощью TestCode, это можно сделать с самыми минимальными усилиями и с максимальной скоростью покрытия тестами функционала.
R>Рекламное бла-бла-бла ни о чем. Пытаетесь потенциального покупателя заболтать? Нет доказательств. Это выглядит как рекламное вранье.
R>Все, что вы пишите пользователям, должно быть не просто правдой, но и иметь доказательства, а это факты, примеры, истории из жизни,
Возьмите класс на 5-10 методов, сделайте тест, что бы компилировался, дайте ссылку или пошлите по почте, давайте сравним.
R>Потому что смотрите замыленными глазами, а нужно смотреть глазами тех, кто никогда не видел ваш продукт и не связан с вами обязательствами
Возможно, и тут очень важна обратная связь.
G>>4.Вставить из буфера код.
G>>Это долго?
R>Врете. Эти действия не приведут к работающему тесту.
Разговор ведь про "количества юнитов" был.
R>Переусложнение сквозит во всем, начиная с количества юнитов
R>Напишите полностью все шаги и увидите, что у вас лишних шагов настолько много, что пропадает желение даже близко начинать писать тесты.
Сейчас полноценное написание теста это
1. copy-paste 3-х кусков (unit, methods, initialization)
2. Создать методы с помощью горяч.клавиши
3. в блоке initialization поменять название класса на свой
4. Описать методы которые будем тестировать с регистрацией
5. введем параметры
6. напишем вызов тестируемых методов.
Это сейчас!
При написании эксперта 1..5 пункт будут делаться автоматом, в 6-й пункт нужно будет ввести корректировку.
ВСЕ!!! Куда быстрее?
Сейчас 6 шагов, потом вообще 1 и то, что бы просмотреть правильность сгенерированного кода.
Эксперт сейчас не запускается так как нужен фидбек и возможно, еще что то поменяется.
R>1. Копирую в проект один хидер.
R>2. Подключаю его запуск в main(), дописывая одну строчку вызова прогонов тестов.
R>3. В любом новом cpp файле я вписываю:
R>#include "test.hpp"
R>TEST() {
На счет С ничего не могу сказать, очень-очень давно не писал на нем.
Но если Вы на делфи, как я выше писал, сделаете проект с тестами, я сделаю свой тест.
Мне это очень интересно.
R>Именно. А ваш чем помогает упростить разработку?
R>Тем, что надо купить ваш продукт, часами разбираться в портянках кода и кучей всего на вашем сайте,
В архиве есть примеры
R>потом проделывать десятки шагов, чтобы только начать.
Пока всего 6
R>какие ждут пользователю, когда код придется модифицировать и все тесты, какие он писал ранее,
Вообще то этом и заключается тестирование!
Что бы при изменении спецификации старые тесты или проходили или должны быть модифицированы. Как по другому проверить правильность кода? Верить разработчику "на слово" не видя тесты?
R>придется переделывать, мучаясь с проблемой железо-бетонной связностью с кодом тестирования, где придется
R>переделывать каждый из тестов. А потом, когда вдруг захочется писать версию 2 проекта,
В архиве примеры где лежат тесты, их 3 вида.
1. Внутри модуля (я фанат этой практики)
2. Внешний файл в виде Include файла
3. Внешний файл в виде отдельного модуля.
Показаны плюсы и минусы этих подходов.
R>А вы даже советуете жестко завязывать тесты с кодом бизнес-логики проекта, считая это плюсом.
R>На деле это такой гемор, в какой не захочет вляпаться опытный программист, какой уже ранее делал так.
Тесты делают на функционал, код должен работать так, как описано в спецификации.
Если меняется спецификация и логика, то должны быть изменены и тесты.
А как по другому полноценно проверить код без тестов?
Программист все равно подготавливает данные, с ними отлаживает функционал, а если пришел тикет об ошибке, то программист так же тестирует — отлаживает свой код, с тестовыми данными, только ручками в отладчике.
Я сейчас просто не представляю, как можно было по другому вести разработку.
R>Весь интернет завален подобным и бесплатно. Вы добавили еще один, да еще и платно.
Да, платно. Так как на разработку нужно время, а время это деньги.
И хорошие специалисты стоят хороших денег.
И средства пойдут в первую очередь на дальнейшую разработку продукта.
R>Чтобы выделиться на рынке, вы должны выделиться. А у вас еще один из многих переусложненный фреймворк.
Я с этим категорически не согласен.
Покажите более простой инструмент тестирования.
R>Не доказали ценность вашего продукта.
Возможно, но я очень хочу это сделать.
