테스트를 해야 하는 이유와 테스트의 분류

• 테스트 코드가 없는 코드가 레거시 코드

• 정상적인 기능이 갑자기 안돌아간다?

• 과거로 회기했다는 뜻인 Regression

• = 회귀버그

• 회귀 테스트가 있는 프로젝트는 개발이 쉬워진다

• 기능을 바꿔도 테스트로 체크하면 되기 때문

• 좋은 사례

• 어디까지가 통합 테스트인가?

• 구글 책에선 이런 단어를 사용함

• 소형 테스트(단위테스트)
• dummy 등을 사용해서 테스트 옆에 사례를 다 만족함
• 속도는 당연 빠름

• 멀티스레드에서 어떻게 동작할지 모르기 때문 결과가 항상 같은 것이라는 보장을 하지 못함
• 외부 모듈이 어떻게 동작하는지 따라 다르니

• End-to-End 테스트

• 여기서 집중해야 될건 소형 테스트

• 여러개를 만들어 코드 커버리지를 넓힐 수 있다.

안티 패턴

• api 테스트만 늘릴 생각을 함
• 며개 안돼고 원했떤 결과만 일치하는지 확인하면 끝 난다 생각하기때문
• 그러면 이런식으로 역 피라미드가 생김
• 예상치 못한 경우로 많이 실패함 (상대적으로 불안해서)
• 코드 거버리지도 약한 편

• 단위 api 테스트가 많을 경우?
• 하지만 안정적인 피라미드가 이상적이다 ( 이유는 설명을 안해줌 )

개념

• 어디에 어떻게 테스트를 하지?
• 행위에 집중

• 흐음..
• 지금짜고 잇는 방식 API 코드긴 하지만

대역

• 아무런 동작을 하지 않는 객체

• 페이크
• 이메일까지 검증까지

• 외부 연동시 많이 사용
• 이메일이 일치하면 사용자값 그냥 내려주는 것
• 모키토를 이용해서 함

• 테스트 더블이랑 동일한 개념 위에 나온 것들
• 전부 목이란 것으로 할 수 있음
• 의미가 살짝 혼란스러움
• 개념적으론 메소드 호출을 확인하기 위한 객체
• 기록을 했다가 나중에 다시확인 할수 있는 위에 코드

• 모든 메소드 호출을 기록하기 위한 객체

• 모키토 -> 연장 -> BDD 모키토

• 위 코드는 모키토

• 이상함 when이 given 섹션에 나옴

• BDD를 사용하면 이런 모호함을 해결 할 수 있따.

• 목은 지양하는게 좋음

• 자연스러운 설계 기회를 놓치게 됨.

• 섹션끼리 재활용 할 수 있고
• 결과를 바로 읽을 수 있다.

테스트 기법

• private 메소드 테스트 해야될까?
• 호출하기 어려움
• NO !
• 메서드 지항 테스트를 하려해서 이런문제가 발생

• 별도의 클래스를 만들어서 의존성을 약하게

• 중복을 하는게 테스트에 더 잘 읽힐 수 있는 경우도 있자

테스트에 논리를 넣지말자

• • • 이런걸 넣지 말자

• 흠 이런 상수로 만들어서 해야되나
• 테스트 코드가 오래 많이 실행되려면 직관적이고 이해 가능하게 짜는게 좋다

의존성 추상화

• 제어의 역전을 이용해 테스트를 좀더 쉽게 하게 바꾸자

이벤트 기록

• 객체지향적인 코드를 만들기위해 gatter / setter를 지양해야되기 대문에

• position 값을 확인해야되니 get을 부득이하게 생김 곤란함

• 행동 이력을 만들어 밖에서 볼수 있게하면?
• 흠 이건 좀 어렵다 와닿지않는내용인데