[react] TDD - 테스트란?

테스팅에 대해

 

테스팅이란 무엇인가?

• software test
  제품 서비스의 품질을 확인, 소프트웨어의 버그를 찾음
  제품 (함수, 특정기능, ui, 성능, api 스펙) 이 예상하는대로 원하는대로 동작하는 지 확인

플랫폼, 목표, 환경에 따라서 다양한 테스트들이 존재한다.

code -(예상하는 요구사항)-> test

예상하는 요구사항에 맞게 동작하는 지? test code를 작성한다.

 

언제 테스트를 해야할까?

원래는 QA에서 테스트를 진행하였는데, 요즘에는 개발을 하면서 자동으로 테스트가 되도록 많이 변화했다.

개발을 하면서 테스트를 하게 되면, 자동화 테스트로 속도가 빠르고, 쉽게 작성할 수 있다. 높은 커버리지를 장점으로 꼽을 수 있다.

사용자 입장에서 제품이 동작해야 하기 때문에 QA는 늘 필요하다.

 

테스트를 하는 이유? 장점?

일하는 시간을 줄일 수 있음 (효율성)

1. 기능이 정상적으로 동작하는 지
2. 요구사항 만족 (확실하게.)
3. 이슈에 대해 예측
4. 버그를 빠르게 발견
5. 자신감 있게 리팩토링
6. 손쉬운 유지보수
7. 코드의 품질 향상
8. 코드간 의존성을 낮춤
9. 좋은 문서화 (굿굿)
10. 시간을 절약

 

테스트 피라미드

unit test : 단위 테스트 : 독립적인 함수, 모듈, 클래스 하나의 단위를 테스트 하는 것.
integration test : 통합 테스트 : 여러가지 단위를 함께 묶었을 때, 상호작용이 잘 되는지 테스트
e2e test : 끝과 끝 테스트 : ui 테스트, 사용자 테스트 : 전체를 테스트. 사용자가 했을 때 발생할 수 있는 테스트 (qa가 많이 하기도 한다)

비용적인 측면,
unit에서 e2e까지 비용이 점점 든다. unit이 가장 싸다.

속도적인 측면,
unit에서 e2e까지 비용이 점점 느려진다. unit이 가장 빠름

이로 인해서, unit 테스트가 가장 많이 사용된다.

 

TDD란 무엇인가?

TDD : Test Driven Development 테스트 주도 개발
개발 전 테스트 코드를 먼저 작성하는 방식

TDD를 하기 위해서, 먼저 테스트 코드를 작성. -> 테스트 코드 실행 -> fail -> 성공할 수 있도록, 그 만큼의 정말 테스트 코드를 통과할 정도의 코드를 작성. -> 성공 -> 다음 테스트로 넘어가서 -> 조금 코드를 또 작성하고 -> 성공

이렇게 무한 굴레로.. TDD를 작성한다.

테스트 코드를 먼저 작성하면서 개발해나가는 방식,
전체 코드를 작성했다면. 자신감 있게 리팩토링 작업을 할 수 있다.

TDD의 큰 장점

1. 테스트코드를 먼저 작성 하기 위해서는, 우리가 무엇을 원하는지? 어떤 코드를 짜야 하는 지? 요구사항에 대한 분석과 철저한 이해가 필요하기 때문임
2. 그리고, 설계하는 방법에서 TDD의 큰 장점이 된다.
   모든 요구사항(목표)에 대한 점검을 할 수 있다.
   사용자 입장에서 코드를 작성 (구현 < 인터페이스 -> 코드의 퀄리티 향상)
   시스템 전반적인 설계가 향상

실패한 테스트 코드를 성공하게끔 만들고 하는 과정에서 게임하듯 코드를 작성할 수 있다. 재밌다는 뜻.

TDD를 하면서, 모든 전체적인 코드를 작성하게 되면, 모든 코드가 성공한 상황일 것임.
그 상황에서 refactoring을 진행하게 된다. 코드를 좀 더 개선하고 깔끔하게 정리한 다음.
테스트가 동작하는 지 확인, (실패한다면.. 어떤 것이 잘못되었는지 수정하고 개발해나간다.)

 

TDD 모든 개발자들이 다 해야할까?

개발자가 main 브랜치에 머지하기 전에, 개발하면서 TDD를 이용하든 하지 않든 개인의 역량이다.
팀이 강제해서 할 수도 있고, 그냥 내가 할 때 TDD를 구현해서 할 수 있다.
강제할 수는 없다!!

기능을 다 구현한 다음 테스트코드를 작성하는 사람이 좋다면 그렇게 해도 좋다..

그것보다 더! 중요한 것은, main에 머지하기 전에 꼭! 테스트 코드와 같이 merge 하는 것을 원칙으로 하는 것이 좋다.
TDD던, 아니던,..

코드 리뷰를 요청하기 전에 내 코드가 사용자에게 배포되기 이전에 그에 해당하는 테스트 코드를 포함하자.
내가 잡은 버그가 전혀 버그가 없다는 것을 검증할 수 있는 테스트 코드를 포함해서 머지를 하자.

<<< 좋은 문서화 >>>

TDD를 할 때도 있고, 하지 않을 때도 있다. 사용자에게 배포해야하는 코드라면 그에 해당하는 테스트코드는 꼭! 작성을 하자.

TDD를 작성할 때 기준점?

• 요구사항이 명확할 때
• 비지니스 로직
• 협업 시 명세서(문서) 역할
• 설계에 대한 고민이 필요할 때.

TDD를 사용하지 않는 경우

• ui 컴포넌트를 작성할 때. (일단 ui를 먼저 만들어 두고, 비주얼 테스트나 그런 것을 작성한다)
• ui 에 필요한 비즈니스 로직을 따로 빼와서 테스트 코드를 항상 작성한다. (이게 중요한 점)

 

CI / CD 에서의 테스트

CI/CD 개념 유튜브 영상:
https://www.youtube.com/watch?v=0Emq5FypiMM

CI / CD 개념

• 개발프로세스

어플리케이션 개발 단계부터 배포까지 자동화를 통해서 사용자에게 빈번하게 배포할 수 있도록 만드는 것

CI 지속적인 통합 CD 지속적인 배포

CI (continuous)

1. 코드 변경사항을 주기적으로 빈번하게 머지해야 한다.(테스트코드 포함)
2. 통합을 위한 단계 (빌드, 테스트, 머지)의 자동화. (merge build test)

장점 (테스트 코드가 있을 때)
개발 생산성 향상, 문제점을 빠르게 발견, 버그 수정 용이, 코드 퀄리티 향상 (unit test)

CD (delivery or deployment) 제공, 배포

배포할 준비과정을 거치고, 정상적인지 검사하면 배포해도 되겠다. 라고 하면 (자동화 배포 or 수동 배포)

개발자가 코드를 작성하면 -> 빌드하고 -> 테스트 과정을 거침 -> 릴리즈 단계 거쳐서 -> 배포

CI/CD 툴

1. jenkins Buildkite
2. github actions
3. gitlab
4. bitbucket

테스트코드 + CI/CD 조합은 매우 좋다.