2014-08-27 2 views
-1

Я относительно новый в письменной форме «ХОРОШИЕ» блок-тесты.Строгое утверждение о возвращенном объекте, необходимом в тестовых случаях?

Мой Pojo класс:

public class User { 

    private String userId; 

    private String email; 

    private String name; 

    public String getUserId() { 
     return userId; 
    } 

    public void setUserId(String userId) { 
     this.userId = userId; 
    } 

    public String getEmail() { 
     return email; 
    } 

    public void setEmail(String email) { 
     this.email = email; 
    } 

    public String getName() { 
     return name; 
    } 

    public void setName(String name) { 
     this.name = name; 
    } 
} 

Мой интерфейс:

public interface UserDao { 

    List<User> getUsersByEmail(String email); 
} 

Мои TestCase является;

public class UserDaoTest { 

    private UserDao userDao; 
    @Test 
    public final void testUsersGetByEmailFunctional() 
    { 
     final String email="[email protected]"; 
     List<User> usersByEmail = userDao.getUsersByEmail(email); 
     Assert.assertNotNull(usersByEmail); 
     for(User user : usersByEmail) 
     { 
      Assert.assertEquals(user.getEmail(), email); 
     } 
    } 

    /** 
    * NOTE : Consider that User.equals() method is not available due to other constraints 
    */ 
    @Test 
    public final void testUsersGetByEmailStrict() 
    { 
     final String email="[email protected]"; 
     final String expectedName="xxx"; 
     final String expectedUserId="123"; 
     List<User> usersByEmail = userDao.getUsersByEmail(email); 
     Assert.assertNotNull(usersByEmail); 
     for(User user : usersByEmail) 
     { 
      Assert.assertEquals(user.getEmail(), email); 
      Assert.assertEquals(user.getName(), expectedName); 
      Assert.assertEquals(user.getUserId(), expectedUserId); 
     } 
    } 
} 

Теперь, мой вопрос: какой тестовый пример наиболее подходит?

http://howtodoinjava.com/2012/11/05/unit-testing-best-practices-junit-reference-guide/

цитата говорит,

Не делайте ненужных утверждения

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

Не пытайтесь Утверждают все просто сосредоточиться на том, что вы тестируете в противном случае вы будете в конечном итоге иметь несколько testcases неудач для одной причине, которая не помогает в достижении ничего.

Что это значит?

ответ

0

Единичный тест обычно означает тестирование во время использования коробки. Итак, вы должны знать свой код и проверить, что он делает, что он должен делать. Если getUsersByEmail отвечает за загрузку данных в поля email/name/id, вы должны утверждать. Если он делегирует загрузку другому тестируемому методу, вам не нужно повторять его повторно. В идеале - любое логическое изменение (я имею в виду не рефакторинг) в главном коде должно разбить ровно один единичный тест.

assertNotNull(usersByEmail) это необязательное утверждение, потому что если оно равно нулю, вы получите NPE в следующей строке.

+0

Спасибо за ваш ответ. Поскольку вы упомянули assertNotNull (usersByEmail), нет необходимости, у меня есть вопрос. Может ли сам тест вызвать исключение. В идеальном случае, если тестовый случай терпит неудачу, я предположил, что это должно быть из-за утверждений, а не самого теста. Поправьте меня, если я ошибаюсь. –

+0

@TariqSulaiman обычно является сигнатурой метода тестирования '@Test public void testSomething() throws Exception'. Любое исключение, возникшее во время теста, делает его красным. – kan

+0

Спасибо за ответ. @kan –

Смежные вопросы