Я использую JUnit 3 и имею ситуацию, где часто я должен протестировать это, объект создается правильно. Моя идея состояла в том, чтобы записать класс MyTestBase
как показано ниже и затем расширяют от этого для ситуации определенные модульные тесты.
Однако в примере я дал, MyTests
не запускает тесты в MyTestBase
.
public class MyTestBase extends TestCase {
protected String foo;
public void testFooNotNull() {
assertNotNull(foo);
}
public void testFooValue() {
assertEquals("bar", foo);
}
}
public class MyTests extends MyTestBase {
public void setUp() {
this.foo = "bar";
}
public void testSomethingElse() {
assertTrue(true);
}
}
Что я делаю неправильно?
Извинения обновления. Глупая ошибка. Тесты в моем базовом классе не назвали правильно.
Вы сказали: «Mytests не запускает тесты в MyTestBase». Я попробовал, и все тесты назывались, включая в MyTestBase.
То, что вы пытаетесь сделать, это не самый подходящий способ добиться своей цели:
Если вы хотите иметь общую функциональность, которая делает некоторые проверки
статических
методов Я не знаю, что именно вы хотите сделать, но обычно это не очень хорошая идея для слишком много общего теста, Поскольку, когда общая часть терпит неудачу, у вас будет большое количество тестов, которые не проходят даже жестко, у вас, вероятно, есть только одна небольшая ошибка в вашем программном обеспечении.
Я предлагаю вам использовать завод или строитель для создания сложного объекта, а затем тестировать завод (или построитель) для правильного создания объекта.
Что ж, вы можете сделать MyTestBase
абстрактным, чтобы он не пытался запускать тесты в базовом классе. Лучшим решением было бы иметь setUp
в базовом классе и заставить его вызывать абстрактные методы (например, getFoo ()
) для инициализации переменных, которые потребуются ему позже.
На самом деле, если у вас есть эти абстрактные методы, вы можете обнаружить, что вам даже не нужна фаза настройки в первую очередь - вы можете вызвать абстрактные методы там, где вам нужно значение, вместо использования переменной экземпляра. Очевидно, это будет зависеть от конкретной ситуации, но во многих случаях это могло бы быть намного чище.