Независимые тесты JUnit с пружинами @Autowired - PullRequest
Новая
       13

Независимые тесты JUnit с пружинами @Autowired

6 голосов
/ 21 июля 2011

Как новичок в разработке через тестирование, я только что столкнулся с проблемой. Мой тестовый класс начинается следующим образом: 

@RunWith(SpringJUnit4ClassRunner.class)
@Transactional
@DirtiesContext
@ContextConfiguration(locations = {"/web-test.xml"})
public class XXTest {

  @Autowired
  XX xx;

  @Autowired
  HibernateTemplate template;

  @Test
  public void testSetGetXXValue() throws Exception {
    final Map<String, YY> profilMap = new HashMap<String, YY>(2);
    profilMap.put("1", new YY());
    profilMap.put("2", new YY());

    simpleCockpit.setValues(profilMap);

    assertEquals(profilMap, simpleCockpit.getValues());
  }

Как видите, первый тестовый метод изменяет класс XX с автопроводкой. Это влияет на все следующие методы тестирования, в которых XX имеет значения autowired.

Как я могу проверить геттер и сеттер из XX и убедиться, что XX имеет значения автопроводки для остальных методов теста?

Мысль:

  • Сброс правильных значений в конце метода испытаний. Плохо, потому что, если геттер / сеттер не работают, это также не будет работать.
  • Поместите первый тестовый метод в конце тестового класса. Плохо, потому что это делает тесты зависимыми от порядка их выполнения.
  • Не тестируйте геттер / сеттер XX. Плохо, потому что метод получения / установки должен быть проверен, как и любой метод.

Спасибо за ваши ответы! Я уверен, что это простое решение ...:)

РЕДАКТИРОВАТЬ : Что касается вопросов, являются ли юнит-тестеры геттерами / установщиками или нет, я решил сделать это главным образом по причинам, изложенным в http://www.sundog.net/sunblog/posts/should-we-test-getters-and-setters/.

1 Ответ

7 голосов
/ 21 июля 2011

Если вы модифицируете управляемый бин весной, вы можете использовать аннотацию @DirtiesContext. Эта аннотация может быть применена как к классам тестов, так и к методам тестов!

С @ DirtiesContext Java Doc:

Тестовая аннотация, которая указывает, что {@link org.springframework.context.ApplicationContext ApplicationContext} связанный с тестом грязный и должен быть закрыт:

  • после текущего теста, когда объявлено на уровне метода
  • после каждого метода тестирования в текущем классе тестирования, когда он объявлен в классе уровень с режимом класса, установленным в {@link ClassMode # AFTER_EACH_TEST_METHOD AFTER_EACH_TEST_METHOD}
  • после текущего класса теста, когда объявлено на уровне класса с режимом класса, установленным в {@link ClassMode # AFTER_CLASS AFTER_CLASS}

И даже в Test Driven Development (насколько я понимаю): писать явные тесты только для вещей, которые имеют минимальную сложность. Поэтому я никогда не пишу точные тесты для getter и setter. У меня обычно есть тест, который проверяет некоторую функциональность, и когда эта функциональность нуждается в геттере и установщике, поэтому я пишу эти геттеры и сеттеры (на данный момент), и то, что они работают, будет проверяться функциональностью, которую я начал неявно.

Особенно в вашем случае: почему вы используете Spring Bean, почему не используете "нормальные" объекты, созданные с помощью new. Я использую «нормальные» классы, если они полезны для тестов, в основном для простых тестов. Я использую Spring Beans и для «больших» тестов.

...