EmptyRectangleTest
public void testEmpty() {
Rectangle empty = new Rectangle(0,0,0,0);
assertTrue(empty.isEmpty());
}
public void testWidth() {
Rectangle empty = new Rectangle(0,0,0,0);
assertEquals(0.0, empty.getWidth(), 0.0);
}
(Помимо прочего зд есь также д емонстрируется версия assertEquals()
д ля чисел с плавающей точкой, которая принимает третий параметр –
точно сть сравнения.) Мы можем избавиться от д ублирования, написав:
EmptyRectangleTest
private Rectangle empty;
public void setUp() {
empty = new Rectangle(0,0,0,0);
}
public void testEmpty() {
assertTrue(empty.isEmpty());
}
public void testWidth() {
assertEquals(0.0, empty.getWidth(), 0.0);
}
Общий код выд елен в вид е отд ельного метод а. Сред а xUnit
гарантирует, что метод setUp() объекта TestCase буд ет обязательно
вызван перед обращением к любому тестовому метод у этого объекта.
Теперь тестовые метод ы выгляд ят проще, од нако, прежд е чем понять их
смысл, мы д олжны вспомнить о существовании метод а setUp() и
уточнить, что происход ит внутри этого метод а.
Какой из этих д вух стилей пред почтительней? Попробуйте
использовать кажд ый из них. Я фактически всегд а выд еляю общий код
фикстуры и перемещаю его в метод setUp(), од нако у меня хорошая
память. Те, кто читает мои тесты, часто жалуются, что им приход ится
вспоминать слишком о многом. Значит, возможно, мне след ует выд елять
меньшей объем код а, чтобы сд елать тесты более понятными.
Взаимоотношения
межд у
под классами
класса
TestCase
и
экземплярами этих под классов являются наиболее запутанной стороной
инфраструктуры xUnit. Кажд ый новый тип фикстуры требует созд ания
нового под класса класса TestCase. Кажд ая новая фикстура созд ается
внутри экземпляра под класса, используется од ин раз, а затем
уничтожается.
В пред ыд ущем примере, если мы хотим написать тесты д ля
непустого прямоугольника (Rectangle), нам прид ется созд ать новый
класс, который можно назвать, например, NormalRectangleTest. У этого
класса буд ет свой собственный метод setUp(), в котором буд ет созд ан
новый экземпляр Rectangle, необход имый ему д ля тестирования. Этот
экземпляр Rectangle буд ет соответствовать непустому прямоугольнику.
В общем случае, если я хочу использовать несколько отличающуюся
фикстуру, я созд аю новый под класс класса TestCase.
Это означает, что не существует прямого про стого соответствия
межд у классами тестов и функциональными (тестируемыми) классами.
Иногд а од на фикстура используется д ля тестирования нескольких
классов (под обное случается нечасто). Иногд а д ля тестирования
ед инственного функционального класса требуется созд ать д ве или три
фикстуры. На практике в большинстве случаев получается, что
количество классов тестов приблизительно совпад ает с количеством
функциональных классов. Од нако это происход ит вовсе не потому, что
д ля кажд ого функционального класса вы созд аете од ин-ед инственный
класс теста.
Do'stlaringiz bilan baham: |