세상을 바꾸는 개발자

비관리 의존성에만 목을 사용 시스템의 끝에서 비관리 의존성과 상호 작용을 검증 목을 스파이로 대체하라(스파이: 직접 작성한 목) 시스템 끝에 있는 클래스의 경우 스파이가 목보다 낫다 통합테스트에서만 목을 사용, 단위테스트에서는 사용x 목은 통합테스트를 위한 것(비즈니스 로직과 오케스트레이션의 분리) 도메인 모델에 대한 테스트는 단위테스트 범주, 컨트롤러 테스트는 통합테스트 통합테스트에서 컨트롤러를 테스트 할때만 목을 적용 테스트당 목이 하나일 필요x 항상 목의 호출 수 확인하기 예상하지 못한 호출 확인 혼자 단위테스트라는 책을 읽으면서 생각에 흐름대로 적은 글입니다. 기록용입니다! 참고한 책은 단위 테스트라는 책입니다. ( http://www.yes24.com/Product/Goods/104084175 )

통합테스트란? 단위테스트의 3가지 요구사항 단일 동작단위 검증 빠르게 수행 다른 테스트와 별도로 처리 → 이 세가지 중에 하나도 충족을 못할 시 통합테스트(단위테스트가 아닌 모든테스트가 통합테스트) 단위테스트와 통합테스트 단위테스트와 통합테스트간에 균형을 유지하는 것이 중요 단위테스트로 가능한 한 많이 비즈니스 시나리오의 예외 상황을 확인하고 통합테스트는 주요 흐름과 단위테스트가 다루지 못하는 기타 예외사항을 다뤄야한다.(모든 프로세스의 외부의존성을 거치는 것) 빠른 실패원칙 : 예기치 않은 오류가 발생하자마자 현재 연산을 중단 프로세스 외부 의존성의 2가지 유형 관리의존성 : 애플리케이션을 통해서만 접근가능 ex) 데이터베이스 등 비관리 의존성 : 외부에서 상호작용을 볼 수 있음 ex) SMTP, 메세..

코드의 4가지 유형(복잡도 또는 도메인 유의성 과 협력자 수를 이용해서 분류) 도메인 모델과 알고리즘 : 복잡도 및 도메인 유의성(상) 협력자수(하) 테스트하는 것이 가장 이로움 간단한 코드 : 복잡도 및 도메인 유의성(하) 협력자수(하) 테스트할 필요x 컨트롤러 : 복잡도 및 도메인 유의성(하) 협력자수(상) 간단한 테스트 필요 지나 치게 복잡한 코드 : 복잡도 및 도메인 유의성(상) 협력자수(상) 두부분으로 나누어야한다.(복잡도 및 도메인, 컨트롤러) → 가장 중요 코드가 더 중요해거나 복잡해질수록 협력자는 더 적어야 한다 좋지 않은 테스트를 작성하는 것보다는 테스트를 전혀 작성하지 않는 편이 낫다 험블 객체 패턴 테스트가 가능한 부분을 추출 (험블래퍼) 단일 책임원칙을 지키자 가치있는 테스트를 위한..

하나의 테스트에서 3가지 스타일을 모두 사용이 가능 출력기반의 테스트 정의(가장 선호해야한다.) 입력을 넣고 출력을 검증하는 방식 전역상태나 내부 상태를 변경하지 않는 코드에만 적용되므로 반환 값만 검증하면 됨 함수형 프로그램에 뿌리를 두고있음(함수형으로 작성된 코드에만 적용가능) 테스트 대상 메서드에만 결합되므로 거짓 양성방지가 가장 우수(리팩터링 내성 가장우수) 유지비 가장 낮음 상태 기반 스타일 정의 작업이 완료된 후 시스템 상태를 확인하는 것(상태는 SUT, 협력자중 하나) 통신 기반 스타일 정의 목을 사용해서 테스트 대상 시스템과 협력자 간의 통신을 검증 유지비 가장 높음 고전파는 통신기반 스타일보다는 상태기반 런던파는 이와 반대 하지만 두분파는 출력 기반 테스트를 사용 함수형 아키텍처 vs 숨..

목(Mock) 테스트 대상 시스템과 그 협력자 사이의 상호 작용을 검사하는 테스트 대역 테스트대역: 모든 유형의 비운영용 가짜 의존성을 설명하는 포괄적인 용어 테스트 대역 목(목, 스파이) : 외부로 나가는 상호작용을 모방하고 검사하는 데 도움 목 : 프레임워크의 도움을 받아 생성(가끔 직접 작성) 스파이 : 수동으로 작성 스텁(스텁, 더미, 페이크) : 내부로 들어오는 상호 작용을 모방하는 데 도움 더미 : 단순하고 하드코딩 된 값 스텁 : 시나리오마다 다른 값을 반환하게끔 구성할 수 있도록 해주는 완전한 의존성 페이크 : 대다수 목적에 부합하는 스텁(아직 존재하지 않는 의존성을 대체) 목과 스텁의 차이 목은 SUT와 관련 의존성을 간의 상호작용을 모방하고 검사하지만 스텁은 모방만 한다 목은 명령이고 ..

회귀방지 회귀는 소프트웨어 버그이다(기능이 의도한대로 동작x) 단순한 코드를 테스트하는 것은 가치가 거의 없다 회귀 방지 지표를 극대화 하려면 테스트가 가능한 한 많은 코드를 실행하는 것을 목표로 해야한다. 리팩터링 내성 테스트에서 얼마나 많이 거짓양성이 발생하는지 살펴봐야하한다(적을 수록 좋음)(거짓음성: 테스트는 잘 동작하지만 기능은 실패) (거짓양성: 기능은 잘 동작하지만 테스트는 실패) 테스트를 실패로 변경하지않고 코드를 리팩터링 할 수 있는지에 대한 척도이다.SUT의 구현 세부 사항과 테스트간의 결합도를 낮추는 것뿐이다 즉, 코드의 내부 작업과 테스트 사이를 가능 한 멀리 떨어뜨리고 최종결과를 목표로 하는 것. → 테스트를 깨지지않게 하고 리팩터링 내성을 높이는 방법 회귀방지와 리팩터링 내성의 ..

안녕하세요~ 헬창코딩 입니다. 참고한 책은 블라디미르 코리코프님이 지으신 UnitTesting란 책입니다. 오늘은 책의 3장의 내용을 정리하고 복습하려고 합니다. 주제 (arrange, act, assert) AAA 패턴의 단위 테스트의 구조에 관한 설명 단위 테스트를 가능한 한 읽기 쉽게 만드는 방법 AAA 패턴 각 테스트를 준비, 실행, 검증 3가지로 단계로 나눌 수 있다. 모든 테스트가 단순하고 균일한 구조를 갖는 데 도움이 된다(일관성이 가장 큰 장점) AAA 패턴의 단계 준비 구절 테스트의 대상 시스템과 해당 의존성을 원하는 상태로 만든다. 실행 구절 테스트 대상 시스템에서 메서드를 호출하고 준비된 의존성을 전달하고 출력값을 캡처한다. 검증 구절 결과를 검증한다. (결과는 반환 값이나 테스트 대..

안녕하세요~ 헬창코딩 입니다. 오늘은 유닛테스트를 공부하면서 중요했던 부분과 생각했던 부분을 생각나는 대로 끄적여 보려고 합니다!! (단순 복습용) 참고한 책은 블라디미르 코리코프님이 지으신 UnitTesting란 책입니다. 저도 안드로이드 개발을 하면서 단위테스트란 말은 수도 없이 들어봤습니다. 그때마다 단위 테스트는 그냥 버그 및 에러 검증을 위해 테스트 코드를 작성해서 테스트하면 것 이라고만 알고 있었습니다. 이게 틀린 말은 아니긴합니다만 어떻게 작성해야 하고 어떻게 테스트를 해야 하는지는 솔직히 잘 몰랐습니다. 그래서 공부를 하게 되었는데요 오늘은 2장의 내용을 되돌아볼까 합니다 2장에서는 단위 테스트의 정의와 3가지 속성을 말하고 있습니다. 작은 단위로 검증 한다. 빠르게 수행한다. 격리된 방식..