developer h1 developer h1

이전 장에서 언급했던 목과 테스트 취약성에 대해 알아본다. 5.1 목과 스텁 구분목과 스텁은 테스트 대역의 유형이다. 5.1.1 테스트 대역 유형테스트 대역 유형에는 더미, 스텁, 스파이, 목, 페이크라는 총 다섯가지가 있다.실제로는 목과 스텁 두가지로 구분되어 사용된다.두 유형의 차이는 아래와 같다.목은 외부로 나가는 상호작용을 모방하고 검사하는데 도움이 된다. 이러한 상호 작용은 SUT가 상태를 변경하기 위한 의존성을 호출하는 것에 해당한다.(ex SMTP 서버)스텁은 내부로 들어오는 상호 작용을 모방하는데 도움이 된다. 이러한 상호 작용은 SUT가 입력 데이터를 얻기 위한 의존성을 호출하는 것에 해당한다. (ex 데이터베이스)5.1.2 도구로서의 목과 테스트 대역으로서의 목목은 상황에 따라 다른 의..

4.1~4.4 좋은 단위 테스트의 4대 요소 회귀 방지테스트가 얼마나 버그(회귀)를 잘 찾아내는지에 대한 척도로, 테스트가 코드를 많이 실행할 수록 증가하는 경향이 있다.리팩토링 내성거짓 양성을 내지 않고 애플리케이션 코드 리팩토링을 할 수 있는 정도를 의미한다.거짓 양성은 허위 경보이다. 테스트는 실패하지만 기능은 문제가 없는 상태를 말한다.빠른 피드백테스트가 얼마나 빨리 실행되는지에 대한 척도이다.유지 보수성테스트 이해 난이도 : 테스트가 작을 수록 읽기 쉽다.테스트 실행 난이도 : 테스트에 관련된 프로세스 외부 의존성은 적을수록 쉽게 운영할 수 있다.회귀 방지 - 리팩토링 내성 - 빠른 피드백은 서로 상호 베타적인 존재이다.테스트는 세가지 특성 중 두가지만 최대화할 수 있다.리팩토링 내성은 타협할 ..

이제 직접적으로 적용할 수 있는 개념이 나와서 개인적인 감상을 덧붙힌다. 3.1 단위 테스트를 구성하는 방법 3.1.1 AAA패턴AAA패턴 : Arrange(준비), Act(실행), Assert(검증)으로 이루어진 테스트 구조.일반적으로 많이 사용하는 Given-When-Then 패턴과 차이는 없다고 볼 수 있지만, AAA패턴은 조금 더 비 개발자에게 공유하기 적합한 용어이다. 더보기나 또한 Given-When-Then을 사용하고 있었지만, 이 패턴에 사용되는 용어는 개인적으로 추상적인 느낌이 있어 런던파의 방식에 어울리는 용어가 아닌가 하는 생각이 들었다.회사에 따라 내부 컨벤션을 살펴봐야 겠지만, 앞으로의 개인 프로젝트는 AAA패턴을 적용할 생각이다.  3.1.2 여러개의 준비, 실행, 검증문 피하기..

단위 테스트는 많은 뉘앙스로 사용되고 있다.이로 인해 해석에 차이가 생겼고, 뚜렷한 두가지 견해로 나뉘었다.각각 고전파와 런던파로 알려져 있다.고전파는 모든 사람이 단위 테스트와 테스트 주도 개발에 원론적으로 접근하는 방식이다.런던파는 런던의 프로그래밍 커뮤니티에서 시작되었고, Mock을 적극적으로 활용하는 것이 특징이다. 2.1 단위 테스트의 정의단위 테스트의 가장 중요한 세가지 속성은 아래와 같다.작은 코드 조각(단위)을 검증한다.빠르게 수행한다.격리된 방식으로 처리하는 자동화된 테스트다.여기서 주관적인 차이가 생기는 것은 첫번째와 세번째인데, 고전파와 런던파를 가르는 것에는 세번째 속성이 결정적인 역할을 한다.런던파는 불변 의존성을 제외하고 테스트 대상 단위 의외의 모든 의존성을 대역으로 대체해야 ..

1.1 단위 테스트의 현황 : 테스트는 프로젝트가 크고, 오래 진행될 수록 나타나는 엔트로피(무질서)를 제어하는 안전망 역할을 한다. 사실상 일회성으로 사용하는 프로젝트가 아니라면 필수적인 요소로 자리잡았다.1.2 단위 테스트의 목표 : 이제는 단위 테스트를 해야하는가 -> 더 좋은 단위 테스트란 어떤 것인가로 논제가 변화하고 있다. 좋은 단위 테스트 스위트란 개발 속도를 지키면서 침체 단계에 빠지지 않게 한다. *  테스트 스위트 : 테스트의 집합1.3 테스트 스위트 품질을 위한 커버리지 지표 1.3.1 코드 커버리지 : 코드의 라인 수를 기준으로, 테스트 영역 / 제품 코드 를 통해 나온 결과를 뜻한다. 이 수치는 많은 곳에서 의미있는 지표로 쓰이고 있으나, 절대적으로 신뢰해도 좋을 지표는 아니다. ..

이전 최종 프로젝트 회고 글에서 언급한 성능 테스트 과정을 담은 글이다.처음 k6와 Grafana를 통해 성능 테스트를 진행하면서 생긴 여러 의문과 해결 과정을 담았다.(다시보니 숲에서 처음보는 곤충을 관찰하듯이 신기해하는 모습이 담긴 것 같기도 해서 부끄럽다...) https://tangpoo.tistory.com/170 최종 프로젝트 회고 (ECommerce 프로젝트)최종 프로젝트에 들어가기에 앞서, 캠프측에서 너무 과하게 잘하는 사람이 쏠리지 않도록 밸런스를 맞출 것을 요구했다.나는 랜덤으로 꾸려지는 팀을 경계했기에 평소에 잘 알고지내던 캠프원tangpoo.tistory.com  테스트 개요성능 개선 작업을 시작하기 전 API의 성능을 기록하고, 성능 개선 이후 변화한 지표와 비교하기 위해 테스트를..

최종 프로젝트에 들어가기에 앞서, 캠프측에서 너무 과하게 잘하는 사람이 쏠리지 않도록 밸런스를 맞출 것을 요구했다.나는 랜덤으로 꾸려지는 팀을 경계했기에 평소에 잘 알고지내던 캠프원들을 모아 직접 팀을 신청했고,내가 팀의 리더를 맡게 되었다. 주제우리가 정한 최종 프로젝트의 주제는 ECommerce이다.이유는 개개인이 원하는 기술을 접목함에 있어서 유연한 기능 확장이 가능하고, 대용량 트래픽 대응 경험을 쌓기에도 알맞은 주제라고 생각했기 때문이다. 기술 : Java, SpringDataJpa, Mysql, Redis, Docker, Prometheus, Grafana, K6        AWS EC2, RDS, ElasticCache, S3, CloudWatch 인원 : BE 4인 Github : htt..

페이징을 요청을 받는 방법이 사람에 따라 차이가 있어서 두 방법의 차이를 알아봤다. 1. 인자 값을 받아서 Pageable 객체를 생성하는 방법 Pageable 객체에 필요한 정보를 하나씩 받아온다. 그 정보를 바탕으로 Pageable 객체를 생성한다. 2. 바로 Pageable 객체를 받아오는 방법 필요한 정보를 모두 Pageable 객체에 담은 채로 요청을 받는 방법이다. 따로 가공할 필요 없이 바로 사용할 수 있기 때문에 코드가 굉장히 편하다. 1번 방법은 서버가 더 많은 부담을 지는 대신, 인자값을 백엔드 개발자가 수정할 수 있다. 2번 방법은 클라이언트가 더 많은 부담을 지며, 서버는 Pageable 객체의 값을 고정한 채로 사용해야 한다.