Программист-прагматик. Путь от подмастерья к мастеру - Хант Эндрю, Томас Дэвид

case 'E': blender.empty;

break;

case 's': System.out.printlnfSPEED: " + blender.getSpeed);

break;

case 'f': System.out.println(<FULL> + blender.isFull);

break;

default: throw new RuntimeException(

"Unknown Test directive");

}

 }

}

catch (java.io.lOException e) {

System.err.println("Tesf jig failed: " + e.getMessage);

}

System.err.println("Completed blending\n");

System.exit(0);

}

Затем появится сценарий оболочки для управления тестированием.

#!/bin/sh

CMD="java dbc.dbc_sx"

failcount=0

expect okay {

if echo "$*" | $CMD #>/dev/null 2>&1

then

...

else

echo "FAILED! $*"

failcount='expr $failcount + 1'

fi

}

expect_fail {

if echo "$*" | SCMD>/dev/null 2> &1

then

echo "FAILED! (Should have failed): $*"

failcount='expr $failcount + 1'

fi

}

report {

if [$failcount -gt 0]

then

echo – e "\n\n*** FAILED $failcount TESTS\n"

exit 1 # In case we are part of something larger

else

exit 0 # In case we are part of something larger

fi

}

#

# Start the tests

#

expect_okay F12345678987654321OE # Should run thru

expect_fail F5 # Fails, speed too high

expect_fail 1 # Fails, empty

expect_fail F10E1 # Fails, empty

expect_fail F1238 # Fails, skips

expect_okay FE # Never turn on

expect_fail F1E # Emptying while running

expect_okay F10E # Should be ok

report # Report results

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

% make % make test

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

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

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

2. Это может быть корпоративным стандартом, но не требованием. Его лучше сформулировать так: "Фон диалогового окна должен настраиваться конечным пользователем. При поставке заказчику цвет будет серым". Еще лучше было бы сформулировать его более широко: "Все визуальные элементы приложения (цвета, шрифты и языки) должны настраиваться конечным пользователем".

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

4. Основное требование, вероятно, выглядит примерно так: "Система предотвращает ввод пользователем недопустимых значений в поля и предупреждает пользователя, если ввод этих значений имеет место".

5. Эта формулировка, по всей вероятности, является жестким требованием.

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