인프런 워밍업 클럽 2기 - BE 클린코드, 테스트코드 스터디 3주차 발자국

인프런 워밍업 클럽 2기 - BE 클린코드, 테스트코드 스터디 3주차 발자국

일주일 간 학습 내용 요약

테스트를 해야하는 이유

  1. 테스트는 귀찮지만 필수적이다

    • 테스트를 하지 않으면 경험과 감에 의존해 개발하게 되고, 커버할 수 없는 영역이 발생하며 유지보수가 어려워진다. 결과적으로 소프트웨어에 대한 신뢰가 떨어지고 피드백이 늦어질 수 있다.

     

  2. 테스트의 목적

    • 빠른 피드백을 제공하고, 자동화로 안정감을 얻는 것이 목표다. 매 순간 소프트웨어의 변화가 발생할 때마다 모든 경우를 고려하고 팀원이 동일한 고민을 해야 한다.

     

  3. 테스트 코드를 작성하지 않으면

    • 소프트웨어의 안정성을 보장할 수 없다.

    • 반대로, 테스트 코드가 병목 현상을 일으키면 유지보수가 어렵고, 잘못된 검증이 이루어질 가능성도 있다.

     

  4. 올바른 테스트 코드의 장점

    • 자동화 테스트를 통해 빠르게 버그를 발견할 수 있고, 수동 테스트 비용을 절약한다.

    • 빠르게 변화하는 소프트웨어를 지원하며 팀의 집단 지성을 이익으로 승격시킨다.

       

    • 초기에는 느려 보일 수 있지만, 장기적으로는 가장 빠른 방법이다.

테스트 주도 개발(TDD)

  1. TDD(Test Driven Development)

    • TDD는 테스트 코드를 먼저 작성하고, 그 테스트를 통과하기 위해 프로덕션 코드를 작성하는 개발 방법론이다.

       

    • 테스트가 구현 과정을 주도하게 되며, 기능 테스트와 구현 순서에 따라 진행된다.

     

  2. RED-GREEN-REFACTOR 주기

    • RED: 실패하는 테스트를 작성한다.

       

    • GREEN: 테스트를 통과하기 위한 최소한의 코딩을 한다.

       

    • REFACTOR: 코드를 개선하면서 테스트가 통과되도록 유지한다.

     

  3. TDD의 이점

    • 복잡도가 낮고 테스트 가능한 코드로 구현할 수 있으며, 엣지 케이스를 놓치지 않도록 한다.

       

    • 빠른 피드백을 받아 유연하고 유지보수가 쉬운 코드를 작성할 수 있고, 과감한 리팩토링도 가능하게 한다.

     

  4. 관점의 변화

    • 전통적으로 테스트는 구현부 검증을 위한 보조 수단으로 여겨졌지만, TDD에서는 테스트와 구현부가 상호작용하며 발전하는 형태로 변화한다.

       

    • 클라이언트 관점에서 피드백을 받는 방식으로 발전한다.

회고

칭찬하고 싶은 점: 테스트코드에 대해 궁금점이 많이 있었는데 강의를 듣고 어느정도 많이 해소됐다.

아쉬웠던 점: 생각보다 시간이 많이걸려서 서둘러 미션을 제출한것이 살짝 아쉬웠다.

보완하고 싶은 점: 시간을 넉넉하게 잡고 미션을 수행해야겠다.


다음 주 학습 목표

• 강의를 완벽히 내것으로 만들고 나머지 미션까지 기한 내에 제출하면 좋을 것 같다.


Day 12 미션


참고강의

박우빈 - Readable Code: 읽기 좋은 코드를 작성하는 사고법

댓글을 작성해보세요.

채널톡 아이콘