Как сделать тесты для проверки кода.

← →
Kolan © (2006-08-01 14:02) [0]

Здравствуйте,
Прочитал в книге Фаулера "Рефакторинг" про самотестирующиеся классы... Идея понятно, но в книге он использует готовый модуль JUnit для тестирования. Есть ли что-то для Delphi?

Пользуетесь ли вы такими методами?

← →
Игорь Шевченко © (2006-08-01 14:12) [1]

> Есть ли что-то для Delphi?

DUnit

← →
Джо © (2006-08-01 14:12) [2]

В D2005 & 2006 в IDE встроен фреймворк для тестирования. См. File/New/Other/Unit test.

← →
Kolan © (2006-08-01 14:20) [3]

> Джо © (01.08.06 14:12) [2]

Нашел :). В Help"е есть описание, буду читать. Может где-то есть и на русском, как у Фаулера?

← →
Kolan © (2006-08-01 14:37) [4]

Вот нашел на королевстве:
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1002
но это анонс только... и ссвлка не работает :(

← →
Kolan © (2006-08-02 12:07) [5]

Все уже разобрался.

PS
Сколькоже в BDS 2006 всего наделано... BDS 2007(если выйдет) наверно будет иметь 1 поле ввода для записи ТЗ, и 1 кнопку - разработать программу :)...

← →
Суслик © (2006-08-02 12:24) [6]

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

в противном случае таким тестам верить нельзя.

> Сколькоже в BDS 2006 всего наделано... BDS 2007(если выйдет)
> наверно будет иметь 1 поле ввода для записи ТЗ, и 1 кнопку
> - разработать программу :)...
> <Цитата

и одну кнопку - вывести список багов, живущих еще с 6 версии, но пока непофиксенных :(

← →
Dok (2006-08-02 12:28) [7]

> Суслик © (02.08.06 12:24) [6]

Добавим:
1. писать сразу же тест на найденую багу.
2. периодически запускать тесты всех классов.
3. всегда(!) запускать тесты класса если внесены изменения.

← →
Игорь Шевченко © (2006-08-02 13:37) [8]

Суслик © (02.08.06 12:24) [6]

> в противном случае таким тестам верить нельзя.

Можно

← →
iZEN © (2006-08-02 13:40) [9]

> Суслик © (02.08.06 12:24) [6]
>
> в противном случае таким тестам верить нельзя.

Можно верить. Если они не отработают, то либо тесты неверны, либо код. Ошибку всё равно искать придётся неважно где. Залогом выполнения тестов служит иправильность тестов, и правильность кода. ;)

← →
Kolan © (2006-08-02 13:47) [10]

> Суслик © (02.08.06 12:24) [6]

Я так понял вы не про тесты модулей а про тесты "функциональности"(как объясняет Фаулер).

Думаю проведение тестов модулей все равно повысит надежность да и гибкость....

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

Вот он, мой случай.. :). Но пока опыта мола буду чуять эффект от рефакторинга :)

> нужен дополнительный сотрудник

Да тут ... сложновато.

Благодарю за разъяснения.

PS
Интересное это дело архитектуру придумывать и перерабатывать... Еще бы реализацию не писать :)

О чем здесь речь? Что за тесты? Что ими тестируют и для чего?

> vidiv © (02.08.06 16:45) [12]
>
> О чем здесь речь? Что за тесты? Что ими тестируют и для
> чего?

См. http://junit.org/index.htm
DUnit сделан по типу этого.

Вот ещё FAQ: http://junit.sourceforge.net/doc/faq/faq.htm

Как сделать тесты для проверки кода. Найти похожие ветки