워밍업 클럽 3기 BE 클린코드&테스트 - 3주차 발자국

3주차 회고 과제를 하면서 테스트 코드 작성이 어려운 코드가 무엇인가에 대해 절실하게 느꼈다. 운이 좋게도 이번 주 팀 프로젝트에서 mvc, jpa 관련 테스트를 작성해야 했었다.강의에서 배운걸 실습할 수 있는 좋은 기회였고, 꼼꼼하게, 테스트는 팀원에게 내 의도를 보여주는 문서라는 생각으로 작성했다.팀 프로젝트에서 내 분량이 적진 않아 빨리빨리 기능 구현을 해야 하는 상황이지만, 테스트 코드를 꼼꼼하게 작성하면서 진행하는 길이 결국 가장 빠른 길이라고 믿고 천천히, 하나하나 나아가려 한다. 아 그리고 당분간 gpt 사용은 지양해야겠따.빅데이터 플랫폼 엔지니어로써 일할 때, 책을 읽고 스택오버플로우, 블로그를 뒤져가며 얻었던 지식들은 아직까지 머리에 또렷하게 남아있지만, gpt를 통해 얻은 지식은 쉽게 얻은 지식이라 그런지 오래가지않는다. 반복해서 물어보게 된다.얻기 어려운 지식일수록 가치있다. 명심하자. 천천히 배우자.

워밍업 클럽 3기 BE 클린코드&테스트 - 2주차 발자국

2주차 회고 차주 계획 및 다짐 다음주부터 리팩토링 프로젝트를 시작한다.일단 소스 코드를 보고 이해해야 하는 상황인데, 테스트 코드를 중심으로 살펴보면 좋을 것 같다.테스트 코드에 녹여진 내용을 보고 의도와 기능을 파악해 볼 예정이다.만약 의도가 잘 나타나지 않는다? 리팩토링 포인트라고 생각하고 해당 부분을 개선해보자.읽기 좋은 코드 강의에서 보았던 역할과 책임 등등의 이론도 적용해보는 좋은 실습 대상으로 생각해보자. 일찍 일어나고, 집중력 있는 하루를 보내자.지금 이 순간이 좋은 추억으로 남으려면, 후회하지 않으려면 열심히 해야 한다.긍정적으로 생각하고, 다른 사람들을 포용할 수 있는 심적 여유를 가지는 일주일이 됐으면 한다.할 수 있다. 힘내자. 웃자. 정리 가장 빠른 길테스트 코드 작성을 소홀히했다.기간 내에 기능을 구현하기 위해 테스트 코드는 제쳐두고 주먹구구식으로 개발하기에 급급했으나,결국 문제점이 발견되어 다시 돌아와 예외처리를 하고 기능을 수정하는 일이빈번했다.결국 테스트 케이스를 제대로 작성하는 것이 가장 빠른 길이다.테스트를 통해 버그를 발견할 수 있고, 기능 변경에 따른 영향도 파악이 가능하며,테스트의 의도를 분명히 함으로써 팀원들 간 생각을 공유할 수 있는 매개체가 된다.가까이 보면 느리지만, 멀리 보면 가장 빠르다.테스트는 귀찮지만 해야한다. 잊지말자. 테스트 케이스 세분화해피 케이스와 예외 케이스 모두 작성해야 한다.특히 경계값이 있는 조건에 대한 테스트 작성이 중요하다. 테스트하기 어려운 영역을 분리하기테스트하기 어려운 영역, 제약조건이 있어 테스트 진행이 어려운 경우, 테스트를 수행할 때 마다 값이 변경되는 경우.외부에서 원하는 값을 주입 가능하도록 변경한다.만약, 테스트가 어려운 메서드라고 생각되는 경우 메서드 설계를 변경해보자.기능 주도로 개발하다보면 위와 같은 상황을 자주 마주할 수 있다. 테스트 주도 개발 방식실패하는 테스트 작성, 초록불을 보기 위한 최소한의 코딩, 리팩토링내가 작성한 코드에 대해 자주, 빠르게 피드백을 받을 수 있음.선 기능 구현, 후 테스트 작성의 단점테스트 자체를 누락(귀찮고 테스트하기 힘들어~), 특정 해피 케이스만 작성, 잘못된 구현 등등..위와 같은 단점을 극복할 수 있다.테스트를 어떻게 할지 고민함으로써 복잡도가 낮은 유연한 코드를 작성할 수 있게 되고,즉시 피드백을 받을 수 있다.테스트 주도 개발 방식을 통해 어떤 식으로 효율적으로 테스트할 수 있을지, 테스트 설계 단계부터 고민해보자.TDD가 만능은 아니지만? 이를 판단하기 위해선 TDD를 극한까지 사용해보아야 한다. 테스트는 문서다.테스트 코드는 프로덕션 기능을 설명하는 가장 좋은 문서다.개발에서의 고민점들을 테스트 코드에 녹여놓았기에 어떤 고민의 결과물을 팀 간 공유할 수 있다.특정 기능의 역할을 파악하기도 쉬울 듯 하다.디스플레이 이름을 섬세하게 작성하자.~테스트 라고 작성하지 말고..문장 형태로 행위와 결과를 기술하기. BDDgiven, when ,then 으로 분리, 시나리오에 기반한 테스트케이스 작성.

워밍업 클럽 3기 BE 클린코드&테스트 - 4주차 발자국

회고운이 좋게도 진행중인 프로젝트에서 Mock을 사용하여 테스트 코드 작성을 해야했다.일석이조라 생각하여 즐겁게 강의를 보았지만? 역시 쉽지 않다.기준을 확실하게 잡는 것이 중요하다고 생각된다.어느 부분까지 테스트를 진행해야 할지, 어느 부분까지 stub 처리를 해야 할지.. 테스트를 통해 검증해야 할 부분을 명확하게 선정해야 한다. 테스트는 문서다.테스트 자체만으로 의도가 전달되어야 한다.여러 테스트에서 공통되는 부분을 제거하는 경우, 개별 테스트의 의도를 해치지 않는지 확인해보아야 한다. 어노테이션 사용 시 알고 쓰자.스프링부트 관련 어노테이션인지 아닌지 확실하게 파악해야 한다.그 또한 테스트의 의도가 담겨있다. private 메서드의 테스트가 필요된다고 생각되면 객체 분리의 신호로 생각하자. 스프링 프레임워크 사용 시 익숙하지 않은 라이브러리를 어떻게 학습해야 하나에 대한 고민이 있었는데, 그에 대한 방법을 강의로부터 찾은 것 같다.써보기 전에 역시 알고 써야 한다. 그 이유가 확실해야 한다. 한달간의 스터디가 끝났다.쉽지 않지만? 끝까지 완주했다는 점에서 나에게 칭찬...어차피 계속 공부해야 한다. 즐기면서 하자구~모두 고생하셨습니다.