제이크 앳 우드의 유명한 기사 "Hardware is Cheap, Programmers are Expensive"과 마틴 파울러의 추천 "Keep the Build Fast"에 대해 생각하고있었습니다.DB-intense "unit-tests"하드웨어가 싼 경우
내 시도 접근 방법 :
시간 자원이 충분하지 않은 경우 대개 두 번째 방법을 선택하지만 대부분 첫 번째 방법으로 선택해야합니다.
비용 효과적인 방법을 찾는 방법은 무엇입니까? 꽤 강력한 하드웨어를 사용하는 첫 번째 방법입니까?
데이터베이스 나 파일 시스템과 같은 외부 테스트를 좋아하지 않습니다. 많은 사람들이 단위 테스트보다는 이러한 통합 테스트를 호출합니다.
이러한 종류의 테스트에서는 실행 속도가 문제가되지만 설정 속도도 문제가됩니다.
사용자 (또는 팀원)는 소스 제어에서 코드와 테스트를 체크 아웃하고 즉시 실행할 수 있어야합니다. 그들은 데이터베이스를 만드는 것을 망칠 필요가 없습니다. 테스트를 실행하기가 어려울수록 유용하지는 않습니다.
테스트에 종속성이 거의없는 경우에도 지속적인 통합이 훨씬 용이합니다.
디스크 및 네트워크 액세스가 메모리 액세스보다 속도가 빠르기 때문에 빠른 하드웨어가 외부 종속성의 단점을 극복 할 수 있다고 생각하지 않습니다. 종속성이없는 단위 테스트를 실행하는 이전 시스템은 디스크 및 데이터베이스에 영향을주는 최신 시스템보다 빠릅니다.
두 옵션 간의 장단점은 규모 문제입니다. 소규모 프로젝트에 단일 프로그래머가 있다면, 접근 방법 1)으로 충분할 것이라고 생각합니다.
하지만 더 많은 테스트를 실행하고 실행해야하는 사람들이 많을수록 장치를 분리하지 않고 통합 테스트를 수행하는 것이 더 큰 단점이됩니다.
정말 고정 비용과 가변 비용의 문제입니다. 엄격한 단위 테스트를 설정하는 데는 시간이 걸릴 수 있지만 프로젝트 규모가 크다면 생산성 향상을 위해 여러 달 동안 소요되는 시간을 줄일 수 있습니다.
언제나처럼, 프로젝트의 특성에 달려 있습니다. 행운을 빕니다!
데이터베이스를 만지는 테스트는 단위 테스트가 아닙니다.
예를 들어, DB-Unit은 통합 테스트를위한 테스트 데이터 설정에만 사용됩니다. DB-Unit은 좋은 도구이지만 나쁜 이름 ('Unit'포함)이 있습니다.
지속적인 통합 서버에서 통합 테스트 (DB에 접근하는)는 일반 단위 테스트와 다른 단계에서 실행됩니다. 서로 다른 에스컬레이션 레벨에서 실행되는 점검을 '단계별 빌드'라고합니다.
데이터베이스가 필요한 테스트를 "단위 테스트"라고해야하는지는 종종 논쟁의 여지가 있습니다. 대부분의 경우 대답은 "아니오"입니다. 내 생각은 - "예"입니다. 왜?
서비스 방법 (단위)가 테스트 되었기 때문에. 이러한 메서드는 데이터 액세스 계층에 종속성을 가지며 데이터 액세스 계층은 차례로 데이터베이스 연결에 종속됩니다. 이제 순수한 단위 테스트 접근법은 종속성을 조롱하는 것입니다.이 경우 DAO입니다. 예상대로 동작하려면이 모의 문안이 상당히 복잡해야합니다. 그렇다면 왜 메모리 내 데이터베이스 (HSQLDB/Derby/JavaDB/..)를 사용하는 대신에 복잡한 모의 (mock)를 만드십시오. 은 런타임 설정의 모의으로 실현 될 수 있습니다.
이제 question-in-memory 데이터베이스는 매우 (논리적으로) 빠릅니다. 이것만으로도 테스트를 실행할 시간을 충분히 낮출 수 있습니다.
또한 나는 Continuous Integration 엔진이 buld (및 deliverable)를 먼저 만들고 실행 한 후 테스트를 실행할 수 있어야한다고 생각합니다. 따라서 일상적인 경우에는 테스트를 기다릴 필요가 없으며 결과가 잘못되어있는 부분을 바로 잡을 수있을만큼 빨리 나타납니다.
Bozho,이 답변에 대한 귀하의 블로그에 내 의견을 확인하시기 바랍니다. – ep3static
답변 해 주셔서 감사합니다. 나는 당신과 동의하지만 질문은이 두 가지 방법의 균형을 찾는 것에 관한 것이 었습니다. 당신은 정교 할 수 있습니까? – ep3static
Chris, 업데이트 된 답변을 너무 많이 주셔서 감사합니다! 그것은 나를 많이 도왔다! – ep3static