세상을 바꾸는 개발자

안드로이드는 자바와 코틀린 2가지 언어로 개발을 할 수 있지만 요즘 자바를 사용해서 개발하는 경우는 찾아보기 힘듬니다 저또한 코틀린을 사용합니다 하지만 사용하면서 잘 몰랐던 부분도 있고 한번도 써보지않는 편리고 좋은 기능들이 많이 존재합니다 그래서 이번에 복습할겸 이펙티브 코틀린의 내용으로 정리를 하려고 합니다. 안정성 - 단위테스트를 만들어라 코드를 안전하게 만드는 다양한 방법이 있지만 가장 궁극적인 방법은 다양한 종류를 테스트 하는 것이다 하지만 비즈니스적인 관점의 테스트는 개발자 관점에서 애플리케이션 내부적으로 올바르게 작동하는지 확인하는 것이 아니라, 사용자의 관점에서 애플리케이션 외부적으로 제대로 동작하는지 확인하는 것이 목표이다 그렇기 때문에 개발자에게 유용하지만 충분하지는 않다. 이러한 문제..

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

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

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

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

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

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