정글에서 온 개발자

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

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

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