정글에서 온 개발자

비공개 메서드원칙적으로 테스트하면 안된다.커버리지가 부족하다면죽은 코드거나,추상화가 누락된 것이다. -> 다른 클래스로 분리해 공개메서드로 빼자테스트해도 되는 경우식별할 수 있는 동작이면 테스트해도 된다.예를 들면 ORM의 비공개 생성자 같은 경우비공개 상태테스트를 위해 노출시키지 말자노출 안된 이유가 있을 것이다. 비공가 상태가 아닌 다른 메서드를 이용해 최종 상태를 체크하자.도메인 지식 유출테스트하려는 코드의 로직을 그대로 구현하지 말자.입력과 출력만 확인한다. - 오히려 이부분을 하드 코딩하자코드 오염테스트에만 필요한 메서드를 만들지 말자  (로그 안 찍게 만드는 스위치 메서드 등)차라리 인터페이스를 만들어서 테스트용 구현을 새로 만든다.인터페이스도 코드 오염의 일종이지만 구현이 없어 손상이 적다...

전제조건데이터베이스 스키마를 형상관리로 관리단순 인스턴스로 관리하는 것에 비해 과거 시점으로 돌릴 수 있는 등 장점이 있다.형상관리 외에서는 스키마를 수정하면 안된다.개발자마다 별도의 데이터베이스 인스턴스 사용테스트 중 운영과 간섭이 없도록 함데이터베이스 배포에 마이그레이션 기반 적용상태 기반 방식은 병합 충돌 처리가 수월마이그레이션은 데이터 모션 문제 해결이 수월모션 문제 해결이 병합충돌 해결보다 중요하다.* 병합 충돌 : 마이그레이션 도중 사용자가 데이터를 수정할 수 있음..?스키마테이블, 부, 인덱스, 저장프로시저 등 SQL 스크립트로 표현된다.데이터베이스에 저장된 데이터라도 변하지 않는 데이터 (참조 데이터) 도 스키마다! (SQL INSERT 형태로 저장)마이그레이션마이그레이션이 커밋 된 후에는..

시스템 끝 (비관리 의존성과 직접 통신하는 부분) 을 목으로 처리하자.중간 단계에 실제 객체가 많을수록 테스트가 견고해진다.리팩터링 내성 향상, 회귀 방지그렇다고 중요하지 않은 부분까지 모두 시스템 끝에서 처리할 필요는 없다. (로깅의 구조 확인 등)스파이 (직접 작성한 목). 시스템 끝에서는 스파이가 목보다 낫다.검증 단계 코드 재사용이 가능하다.가독성이 개선된다.라이브러리가 제공하는 Mock도 결국 제품 코드다. 완전히 믿을 수 없다. 믿을 수 있는 건 직접 작성한 테스트코드 뿐단위 테스트에서는 목 안 쓴다!테스트에 사용된 목의 수는 상관 없다.  - 한 동작 단위에서 얼마든지 많아질 수 있고, 이는 통제 범위 밖이다.목의 호출을 체크하자 (원하는 게 호출 됐는지,  쓸데 없이 추가 호출 됐는지)보유..

통합테스트 이유단위 테스트에만 전적으로 의존하면 시스템이 전체적으로 잘 작동하는지 확신할 수 없다.단위 테스트가 아닌 테스트는 모두 통합테스트다.단위 테스트는 도메인 모델을 다루고, 통합테스트는 프로세스 외부 의존성과 도메인 모델을 연결하는 코드를 확인한다.어플리케이션이 간단할수록(도메인 로직이 없을 수록) 통합테스트 수와 단위테스트 수가 같아진다. (단위테스트가 오히려 없을 수도 있다.)주의사항통합테스트는 주요흐름(happy path)와 단위테스트가 못 다루는 예외상황(edge case)를 다룬다.외부 의존성과의 상호작용을 모두 확인하도록 작성하고, 부족하면 모두 확인하게 추가 작성한다.빠른 실패 (코드에서의 예외 던지기) 를 하면 테스트가 필요없다. 이를 통해 통합테스트의 추가 작성 비용을 줄일 수 ..

오늘의 팁추상화할 것(구현체)을 테스트하기보다 추상화를 테스트하는 것이 더 쉽다.도메인 이벤트는 프로세싀 외부 의존성 호출 위의 추상화도메인 클래스의 변경은 데이터 저장소의 향후수정에 대한 추상화컨트롤러에 비즈니스 로직이 있는 것을 완전히 피할 수 없다.도메인 클래스에서 모든 협력자를 완전헤 제거할 수 있는 경우도 거의 없다.    그러나 최소한 외부 프로세스는 참조하지 않게 하자.    그리고 남은 협력자들과의 호출은 구현 세부 사항이다 -> 상호작용을 검증하지 말자어떤 협력자와 어떻게 소통해서 결과를 내는지는 검증하지 말자.그러나 해당 협력자의 소통 메서드는 검증할 수 있다. (더 아래 레이어로 내려가서)세부사항인지, 식별가능인지의 구현은 클라이언트가 누구냐에 달려있다.양파껍질처럼 계층을 바꾸면서 클..

테스트의 효과단순한 검증이라기보다는 설계의 문제다.프로그래머가 수정 중 중요한 것을 망가뜨릴 염려를 없앨 수 있다.프로그래머가 다른 관점에서 문제를 해결할 수 있다. - 호출자 관점에서 보게 된다. -> 편리하게 호출할 수 있는 소프트웨어를 설계하게 된다.반드시 테스트 가능한 프로그램을 설계하도록 강제할 수 있다. -> 소프트웨어를 다른 환경과 분리하도록 강제한다.테스트 자체가 문서화다.인수테스트인수 테스트는 기능 요소의 궁극적인 문서화 형태다.인수테스트 고려가 시스템의 아키텍처에 큰 영향을 준다. -> 인수테스트를 스크립트나 XML로 하기 위해 자연스럽게 트랜잭션 소스, 출력 매커니즘 등을 분리하게 된다.리팩토링모듈을 읽기 쉽고 변경하기 쉽게 만들기 위해 필요한 것은 원칙과 패턴에 더해 주의력과 훈련이..

Master node 구성요소kube api server -> 다른 노드들에 신호 보냄controller manager - 노드 컨트롤러, replication 컨트롤러ETCD clusterkube schedeuler -> 컨테이너 감시Node 구성 요소kublet - masster로부터 신호를 받음kube proxy - 다른 노드들과 통신Dockder와 ContainerDCRI (Container Runtime Interface) - 컨테이너와 쿠버네티스 간의 통신 프로토콜을 정의OCI (Open Container Initiative)  컨테이너 표준을 정하는 단체   - Image spec, runtime spec이 있음원래 도커는 CRI를 지키지 않아(도커가 CRI보다 먼저 생겼음) kubernet..

문제상황개발된 프론트에서 서버로 전송하는 body가 너무 요소가 많아서, 실서비스에서 보내는 request를 잡으려고 개발자도구의 Network를 이용했다. 그런데, 하필 요청이 업데이트를 하는 POST요청을 보내고 새로고침을 하는 바람에, 기록된 요청도 함께 사라져버려서 해당 요청을 클릭할 수 없었다.해결방법이런 경우 EventListener나 실제 코드에 break point를 걸 수 있는데, Angular로 빌드된 파일이 난독화돼있어 실제 코드에 걸기는 어려웠다. (react는 이런 경우 디버깅할 수 있는 툴을 따로 제공해주던데 angular는 내가 전담이 아니라 아직 모르겠다.)해결 방법을 찾던중 chrome 에서 XHR/Fetch가 발생할 때 break point를 걸 수 있는 기능이 있는 걸 ..

vector로 투포인터를 할 때, index를 벗어나는 문제를 방지하거나 좀 더 모던하게 사용하게 위해 vec[i] 와 같은 인덱싱 접근 대신 vec.begin() ,vec.end() 처럼 iterator를 선언해 인덱스에 접근할 수 있다.vector vec = {1,2,3,4,5};auto f = vec.begin();auto b = vec.end()-1;while(f그러나 위 코드의 경우 vec에 값이 없을 때 문제가 될 수 있다.vec.end()-1을 했을 때 예상하지 못하는 문제가 발생할 수 있다.  vec[i-1] 보다는 나을 수 있는 게, 일부 컴파일러는 문제를 미리 잡아줄 가능성이 있다.하지만 문제를 일으키지 않기 위해 더 깔끔한 메소드가 있다.vec.rbegin() 을 하면 뒤에부터의 시작..

테스트의 3가지 종류출력 기반 - 가장 좋음상태 기반 - 그 다음 안 좋음. 고전파가 선호통신 기반 - 가장 안 좋음 . 런던파가 선호상태 기반 테스트는 안정성을 위해 더 신중해야 한다. 유지보수가 쉽지 않다.통신 기반 테스트도 안정성에 신중. 목도 공간을 많이 차지해 가독성이 안 좋다.캡슐화를 잘하면 통신 기반도 리팩터링 안정성을 많이 지킬수 있다.유지보수성 지표테스트를 이해하기 얼마나 어려운가?(테스트 크기)테스트를 실행하기 얼마나 어려운가?(프로세스 외부 의존성의 크기)함수형 프로그래밍외부로의 부작용, 숨은 매개변수가 없어야 한다. 테스트 용이성을 상당히 높힌다.의존성이 시그니처에 없더라도, 불변이라면 숨은 매개변수가 아니다.비즈니스 로직과 부작용을 분리하는 것이 목표다. (완전한 제거는 불가능하므..