[토비의 스프링] 2장 테스트

내용을 정리한 글은 워낙 많아서 깨달음을 얻은 부분 위주로 정리했다.

---

 

스프링으로 개발을 하면서 테스트를 만들지 않는다면 이는 스프링이 지닌 가치의 절반을 포기하는 셈이다. 테스트란 내가 예상하고 의도했던 대로 코드가 정확히 동작하는지 확인해서, 만든 코드를 확신하게 해주는 작업이다. 코드의 결함을 제거하기 위해 디버깅을 거치게 되고, 최종적으로 테스트가 성공하면 모든 결함이 제거되었다는 것을 알 수 있다.

 

단위 테스트

• 테스트의 관심이 다르다면 테스트할 대상을 분리하고 집중해서 접근해야 한다.
• 단위는 작을수록 좋다.
• 단, DB상태가 매번 달라진다면 단위 테스트로서의 가치가 없어진다.
• 단위 테스트를 하는 진짜 목적 : 에러 원인을 빨리 찾기 위해서이다.

 

인터페이스를 활용하여 DI를 적용해야 하는 이유

• 소프트웨어 개발에서 절대로 바뀌지 않는 것은 없기 때문이다.
• 클래스의 구현 방식은 바뀌지 않는다고 하더라도, 인터페이스를 두고 DI를 적용하면 다른 차원의 기능을 도입할 수 있기 때문이다. 새로운 기능을 넣기 위해 기존 코드를 수정하지 않아도 된다.
• 테스트를 하기 위함이다. 테스트를 효율적으로 만들기 위해서는 DI를 적용해야 한다. DI는 단위 테스트가 독립적으로 만들어지고 실행되도록 한다.

---

• 테스트는 자동화되어야 하고, 빠르게 실행되어야 한다.
• 테스트 결과는 일관성이 있어야 한다. 코드의 변경 없이 환경이나 테스트 순서에 따라 결과가 달라지면 안 된다.
• 충분한 검증을 하지 않는 테스트는 없는 것보다 나쁘다.
• 코드 작성과 테스트 수행의 간격이 짧을수록 좋다.
• 테스트하기 쉬운 코드가 좋은 코드다.
• @Before, @After을 사용하면 테스트 메서드들의 공통 준비 작업 및 정리 작업을 처리할 수 있다.
• @Autowired를 사용하면 Context 빈을 테스트 객체에 주입할 수 있다.
• 오류가 발견될 경우 그에 대한 버그 테스트를 만드는 것이 좋다.