개념

• SUT
  • System under test (테스트 하려는 대상)
• BDD
  • Behaviour driven dvelopment(given - when - then)
  • 테스트를 하려는 순간 어디에 어떻게 넣어야 하지 라는 질문을 마주하게 됩니다. 그때 BDD 가 말한다 "행동에 집중해야 한다"
  • 유저가 시스템을 사용하는 user story 를 강조하고 시나리오를 강조한다.
  • 이를 지키기 위한 뼈대로 다음과 같은 구조로 테스트코드를 추천한다.
    • given - 어떤 상황이 주어졌을 떄
    • when - 이 행동을 한다면
    • then - 결과는 이렇다
  • 3A 라고 불리기도 함.
• 상호 작용 테스트 (Interation test)
  • 대상 함수의 구현을 호출하지 않으면서 그 함수가 어떻게 호출되는지를 검증하는 기법(메서드가 실제로 호출됐는지 검증하는 테스트)
  • 상태 기반 검증(state-based-verification)
    • 어떤 값을 시스템에 넣었을 때, 나오는 결과값을 기대값과 비교하는 방식
  • 행위 기반 검증(behaviour-based-verification)
    • 상호 작용 테스트라고 보면 됨(어떤 값을 시스템에 넣었을 때, 협력 객체의 어떤 메서드를 실행하는가)
•  테스트 픽스처
  • 테스트에 필요한 자원을 생성하는 것
• 비욘세 규칙
  • 상태를 유지하고 싶었다면, 테스트를 만들었어야지
  • 유지하고 싶은 상태가 있으면 전부 테스트로 작성해주세요. 그게 곧 정책이 될 겁니다.
• Testablility
  • 테스트 가능성. 소프트웨어가 테스트 가능한 구조인가?
  • 얼마나 쉽게 input 을 변경하고, output 을 쉽게 검증할 수 있는가?
  •  
• Test double
  • 테스트 대역
  • ex)회원가입시 이메일이 발송된다면 -> 이메일을 매번 날릴 수 없으니 가짜 객체를 넣어준다.
    • dummy
      • 아무런 동작도 하지 않ㅇ고, 그저 코드가 정상적으로 돌아가기 위해 전달하는 객체
      • dummy객체에서 이메일은 샌드하는 메서드를 호출하지만 아무런 내용이 없다
    • fake
      • Local 에서 사용하거나 테스트에서 사용하기위해 만들어진 가자 객체, 자체적인 로직이 있다는게 특징
      • 이메일을 보내고 내용을 확인하고 싶을때, map 같은 변수에 담아 get 할 수 있는 메서드를 따로 분리하여 호출한다.
    • stub
      • 미리 준비된 값을 출력하는 객체
      • if(injin.dev@gmail.com)이라면 어떠어떠한 값을 return 한다.식으로 미리 만들어 논 값
      • mockito 프레임워크를 이용해 주로 구현 함
    • mock
      • test double 하고 거의 동일한 개념
      • 메소드 호출을 확인하기 위한 객체, 자가 검증 능력을 갖춤
    • spy
      • 메소드 호출을 전부 기록했다가 나중에 확인하기 위한 객체
      • 메서드가 몇번 호출 됐는지, 잘 호출됐는지 등을 검증