Каковы преимущества тестирования с NUnit?

← →
Prohodil Mimo © (2005-10-19 00:44) [0]

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

Есть ли где материалы по этому делу на русском? На английском этого добра хватает, а вот русские не попадаются.

Может кто сможет привести пример где именно полезно тестирование через NUnit? Не кусок кода, а именно ситуации.

← →
Игорь Шевченко © (2005-10-19 01:09) [1]

> Может кто сможет привести пример где именно полезно тестирование
> через NUnit? Не кусок кода, а именно ситуации.

Наример, ситуация простая - один раз протестировал, внес изменения, желаешь убедиться, что все продолжает работать также, как раньше.

← →
Lamer@fools.ua © (2005-10-19 09:21) [2]

+ к [1]

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

← →
Гаврила © (2005-10-19 10:10) [3]

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

Иногда это очень помогает, иногда это вообще невозможно реализовать, так что все зависит от ситуации

← →
Prohodil Mimo © (2005-10-19 10:42) [4]

Гаврила © (19.10.05 10:10) [3]
подсовываешь ему все возможные сочетания входных параметров

А если их мульён? Я должен для каждого из них сгенерить ответ и в тест засунуть?

← →
Игорь Шевченко © (2005-10-19 10:43) [5]

Prohodil Mimo © (19.10.05 10:42) [4]

> А если их мульён? Я должен для каждого из них сгенерить
> ответ и в тест засунуть?

Безусловно

← →
Гаврила © (2005-10-19 10:55) [6]

Я так понял, главная цель применения такого тестирования- исключение ситуации "в одном месте что-топоправили, в другом из-за этого все съехало, а никто сразу и не заметил"

← →
Mystic © (2005-10-19 12:03) [7]

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

← →
Игорь Шевченко © (2005-10-19 12:05) [8]

Mystic © (19.10.05 12:03) [7]

А что, таким методом кто-то, кроме Бека, пользуется ? :))

← →
TUser © (2005-10-19 12:06) [9]

А что такое NUnit (объясните для тех, кто в бронепоезде)?

← →
Mystic © (2005-10-19 12:48) [10]

> А что, таким методом кто-то, кроме Бека, пользуется ?

Пользуются как минимум несколько моих знакомых :) Иногда я так пишу, в основном когда хорошие идеи сразу не приходят.

← →
Гаврила © (2005-10-19 12:55) [11]

> [9] TUser ©

NUnit is an open-source unit test framework based on the JUnit test framework. The NUnit framework allows you to build and execute tests against .NET Framework applications. The Delphi 2005 integration of NUnit allows you to test both Delphi for .NET and C# applications.

Добавлю, что и не только for .NET

← →
Игорь Шевченко © (2005-10-19 12:56) [12]

Mystic © (19.10.05 12:48) [10]

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

← →
pasha_golub © (2005-10-19 12:57) [13]

> Mystic © (19.10.05 12:03) [7]

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

← →
Mystic © (2005-10-19 20:04) [14]

> но вот из текста книги я все-таки не усмотрел преимущество
> именно писания тестов перед написанием классов.

ИМХО: У К. Бека в XP увязывается много методок. И написание теста до кода кроме всего прочего позволяет объяснить второму программисту свою идею касетельно того, как класс должен выглядеть. В реальной жизни обычно объяснять никому ничего не надо и часто то, что должно быть написано, представляется ясно. Иногда я позволяю себе прирно такой ход мыслей:

Мне надо реализовать некий объект --- таблицы для работы компилятора. Что для этого мне хотелось бы иметь? По спецификации локальная переменная может использовать неявно. Поэтому в этом случае хотелось бы иметь примерно такое:

procedure TestNewId; var V: TName; begin V := Compiler.Table.Lookup("a", Create); CheckEquals(V.Owner, Compiler.Current.Owner); end;

Задекларированый символ надо внести таблицу:

procedure TestDeclaretion; var V: TVar; F: TName; const VarName = "some_temporary_var"; // It does not exist in loaded state begin V := Compiler.Table.CreateVar(); F := Compiler.Table.Lookup("some_temporary_var"); CheckEquals(V.NAme, F.Name); end;

А вот ошибку удобнее обрабатывать так:

procedure TestDeclaretionError; var V: TVar; F: TName; begin V := Compiler.Table.CreateVar("a"); CheckEquals(Compiler.Table.CreateVar("a"), nil); CheckEquals(Compiler.Table.CreateVar("a"), nil); CheckEquals(Compiler.Table.CreateVar("a"), nil); CheckEquals(Compiler.Table.CreateVar("a"), nil); end;

После написания тестов то, что с чем взаимодействует, становится более ясным...

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

Например?

← →
Игорь Шевченко © (2005-10-19 23:11) [15]

Mystic © (19.10.05 20:04) [14]

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

Не совсем понимаю мысль. Тесты помогают проверить соответствие реализации метода или взаимосвязи реализаций методов задуманной функциональности, а каким образом написанные тесты могут помочь другому программисту уяснить, как должен выглядеть класс (надо понимать, то, как выглядит класс, является в большей степени его интерфейсом, чем реализацией), я, честно говоря, не совсем понимаю. Точнее, совсем не понимаю. От приведенного тобой кода тестов мне не стало понятней, как должен выглядеть класс, реализующий методы Compiler.Table, кроме того, повторение одной и той же проверки 4 раза в последнем тесте вносит в мое понимание полную путаницу.

← →
Prohodil Mimo © (2005-10-19 23:37) [16]

Игорь Шевченко © (19.10.05 23:11) [15]
кроме того, повторение одной и той же проверки 4 раза в последнем тесте вносит в мое понимание полную путаницу

я тоже ничего не понял.

← →
Mystic © (2005-10-20 12:27) [17]

Скорее даже не как должен выглядеть класс, а уточнить, какой интерфейс требуется от класса.

> повторение одной и той же проверки 4 раза в последнем тесте
> вносит в мое понимание полную путаницу.

Проверка 4 раза это по пути одной из ошибок, когда первый вызов отработал правильно, а остальные что-то создавали...

← →
Sandman29 (2005-10-20 12:31) [18]

Скорее даже не как должен выглядеть класс, а уточнить, какой интерфейс требуется от класса.

Если лень писать техпроект, пишут тесты? :)

← →
Игорь Шевченко © (2005-10-20 16:04) [19]

Mystic © (20.10.05 12:27) [17]

> Проверка 4 раза это по пути одной из ошибок, когда первый
> вызов отработал правильно, а остальные что-то создавали.
> ..

Я не совсем понимаю, почему именно 4 раза, и кроме того, почему, если метод отработал правильно, дополнительные вызовы метода с аналогичными параметрами могут отработать некорректно ?
Я бы такой тест разнес бы на два, как минимум - в первом вызывал бы проверку правильности "несоздания" чего-то, во втором - проверял бы причины, когда последующий вызов может работать иначе, чем при нормальном поведении.

← →
Суслик © (2005-10-20 16:26) [20]

> [8] Игорь Шевченко © (19.10.05 12:05)
> Mystic © (19.10.05 12:03) [7]
>
> А что, таким методом кто-то, кроме Бека, пользуется ? :))

иногда я.

Пример (для автора в том числе). Так уж сложилось, что мне приходится много заниматься gui (т.е. писать контролы, хотя понимаю в этом слабо). Нужно было написать функцию вывода на экран текста с разбиением на строки. Штатная из winapi (не помню как называется, drawtext, кажется). Не удовлетворяла т.к. в строке еще есть специфические теги. Функция была имела прототип:

TTextWidthFunction = function(Text: String): Width; MyDrawText(Text: String; Lines: TStringList; TextWidthFunction: TTextWidthFunction).

Функция разбивает Text, выводя результат в Lines, для определнеия ширины строк используется функция, переданная в параметре TextWidthFunction.
Я хорошо знал, что хочу получить.

Написал тест, передавая в MyDrawText специальную функцию TestTextWidthFunction.

Типа такой:

function TestTextWidthFunction(Text: String): Integer;
begin
Result := 0;
for I := 1 to Length(Text) do
case Text[0] of
"a": Inc(Result, 2);
"b": Inc(Result, 3);
"c": Inc(Result, 5);
и т.д.
end;
end;

Составил тесты. Например, строка "ab cdbd" должна разбиваться так:
Lines[0] = "ab ";
Lines[1] = "cdbd";

Тесты составлял руками. Придумал штук 50.

После этого сделал автоматизированную проверку тестов. Потом написал функцию.

Когда все 50 тестов отработали я создал еще штук 100. Но уже разбивая разработанной функцией случайно сгенеренную строку. Выборочно результаты работы функции я проверил руками (вернее глазами).

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

В рабочем варианте в качестве функции подставлял реальную функцию из TCanvas: TextWidth.

В моем примере автоматизированный тест был направлен в помощь в разработке.

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

-----------

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

ИМХО.

← →
Игорь Шевченко © (2005-10-20 16:31) [21]

Суслик © (20.10.05 16:26) [20]

> Самый главный вывод, который я сделал об автоматизированном
> тестировании - написанием тестов НЕ должны заниматься программисты.
>

Ты сделал неправильный вывод. Бек учит совсем другому.

> Выборочно результаты работы функции я проверил руками (вернее
> глазами).
>
> В итоге 150 случаев образовали автоматизированный тест,
> который я переодически выполняю.

Не совсем понятно, что проверяют 150 тестов. Разбиение на строки согласно алгоритму ? В этом случае 150 вроде не требуется. Вывод разбитого теста на экран ? Тогда причем тут автоматизация...?

← →
Суслик © (2005-10-20 16:38) [22]

> [21] Игорь Шевченко © (20.10.05 16:31)

> Ты сделал неправильный вывод. Бек учит совсем другому.

Ты историю Бека знаешь? Ну там список успешных проектов и все такое?

> Вывод разбитого теста на экран ? Тогда причем тут автоматизация...?

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

Суслик © (20.10.05 16:38) [22]

> Ты историю Бека знаешь? Ну там список успешных проектов
> и все такое?

Немного знаю :)

> Я приводил пример, когда NUnit (его аналог) решели 2 задачи:
> тест, на основе которых должа была быть написана функция
> + последующее регрессивное автоматическое тестирование

Да, это понятно. Только вопрос у меня был - что тестировалось ?

> Только вопрос у меня был - что тестировалось ?

Алгоритм разбиения на строки.

> Немного знаю :)

Насколько я знаю, он его история не очень успешна.

Суслик © (20.10.05 16:42) [24]

> Алгоритм разбиения на строки.

Настолько сложный алгоритм, что требуется не менее 150 тестов ? Хотя для HTML наверное и побольше будет...

> Насколько я знаю, он его история не очень успешна.

У нас разные сведения, по-видимому. Вот по Яндексу он особо неуспешным не выглядит :)

Суслик © (20.10.05 16:26) [20]
Для этого нужен специалист автоматизации тестирования. К сожалению, я не знаю руководителей, которые готовы деражть такую должность

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

Спасибо, разъяснили даже более чем ожидал :о)
Теперь мне всё ясно.

Я тут вчера подумал и решил кое что добавить.

Не думаю, что я уникум и только я пишу после написания какого-то алгоритма тестики. Маааленькие такие и простенькие. Я лично это делаю на каждый случай, который поддается тестированием кодом (т.е. не GUI. говорят его тоже можно тестировать тестами, но я все-таки пока это делаю глазами по документации).

Например, написал простенькую утилиту (класс) логирования неких действий. Не знаю как другие, но я не поведу этот класс "в бой", если не проверю на тестовом примере, что он работает. Например, не залогирую некое тестовое сообщение и не проверю, что в созданном файле появилось именно оно.

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

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

PS. Выше ИШ заметил, что не согласен со мной, что тесты не должны писать программисты. Я бы хотел поправиться в том, что я не считаю, что программисты вообще не должны писать тесты. Конечно, простые тесты они ОБЯЗАНЫ (как мне кажется) писать - иначе как они проконтролируют качество своей работы. Другой вопрос, что на сложные развернутые тесты у программистов просто нет времени. На это уже нужен специальный человек (опять же - как кажется мне).

> Конечно, можно написать либо маленькое тестовое приложение,
> либо маленькую тестовую форму в основном приложении или
> еще что. Но если так подумать, то твой труд по написанию
> этих замечю, необходимых с моей точки зрения тестов, может
> пропасть: написал тествое приложения, проверил, что все
> ОК и забыл про него. Можно же пойти другим путем - "забить"
> тест в некий специализированный фреймворк (например, в тот-
> же NUnit или DUnit или свой аналог). И иметь возможность
> пользоваться данным тестом на любой стадии разработки проекта.
>

Что я, собственно, и делаю. В Delphi до версии 2005 использую свой фреймворк, а в 2005 - стандартный.

> [29] Игорь Шевченко © (21.10.05 12:21)

> Что я, собственно, и делаю. В Delphi до версии 2005 использую
> свой фреймворк, а в 2005 - стандартный.

Вот и достигнуто согласие и понимание.

Unit-тестирование подменяет контрактное программирование (в терминах Бертрана Мейера).
То, что пытаются сейчас делать путём прикрутки (JUnit, DUnit, NUnit), уже давно есть в языке Eiffel в семантике самого языка!!

Каковы преимущества тестирования с NUnit? Найти похожие ветки