[F-Lab 모각코 챌린지 61일차] The Testing Pyramid

Nami·2023년 7월 31일
0

66일 포스팅 챌린지

목록 보기
61/66
post-thumbnail
테스트 코드를 공부 중인데 The Testing Pyramid를 알게되었다. 어떤 것인지 알아보자!

(일러스트로 내가 만들어본 Testing Pyramid)

The Testing Pyramid

소프트웨어 개발에서 다양한 종류의 테스트를 조합하여 높은 품질의 소프트웨어를 구축하는 방법을 설명하는 모델이다. 마틴 파울러(Martin Fowler)와 노트북 홀더(Nat Pryce)가 제시한 개념으로 유명하다.

  • 개발자와 QA가 모두 고품질 소프트웨어를 구축할 수 있도록 하는 프레임워크
  • 개발자가 수행한 업데이트가 코드에 영향을 미치는지 확인하는 데 필요한 시간을 최소화
  • 테스트 자동화 피라미드라고도 함.
  • 개발 및 QA팀이 자동화된 테스트 스위트에 포함해야하는 테스트 유형을 설명하고 평가의 순서와 빈도를 정의함.
  • 코드 변경이 기존 기능에 영향을 미치지 않도록 하기위해 빠른 피드백 제공

Pyramid functions at three levels

Unit tests 유닛 테스트

  • 테스트 피라미드의 기반 역할을 한다.
  • 제한된 범위 내에서 동작하며, 독립된 코드 유닛이 기대한대로 작동하는지 확인한다.
  • 유닛 테스트는 단일 변수를 평가하고 외부 종속성에 의존하지 않아야된다.
  • 소프트웨어의 가장 작은 단위인 개별 코드 유닛을 테스트한다.
  • 모듈, 함수 또는 클래스 단위로 테스트하며, 외부 의존성을 최소화하여 빠르고 격리된 환경에서 수행된다.
  • 테스트의 목적은 개별 코드 유닛이 의도한대로 정확하게 작동하는지 확인하는 것이다.
  • 사전(pre-commit)과 사후(post-commit) 커밋 테스트를 실행해야하고, 테스트는 개발자가 직접 trigger한다.

Integration tests 통합 테스트

  • 유닛 테스트보다 큰 단위의 기능을 테스트한다.
  • 애플리케이션 내의 다른 코드들과 상호작용하는지를 검증
  • 여러 유닛이 함께 작동하는 상태를 검증하고 각 유닛의 상호 작용이 예상대로 이루어지는지 확인한다.
  • 보통 데이터베이스, 외부 서비스, API 등과의 상호 작용을 테스트한다.
  • 일반적으로 유닛 테스트보다 느리다
  • 가상 디바이스와 실제 디바이스를 적절히 조화롭게 사용하는 것이 중요하다.

E2E tests 인터페이스 테스트

  • 소프트웨어의 전체 시스템 또는 모듈을 완전히 시뮬레이션하거나 실제 사용자 환경에서 시험한다.
  • 방대한 양의 코드(전체 애플리케이션)를 검사
  • 유지 관리 비용이 가장 많이 들고 작동 속도가 가장 느리다.
  • 사용자의 시나리오를 재현하여 소프트웨어가 실제로 기대한 대로 작동하는지 확인한다.
  • UI 테스트, 시스템 테스트, 인수 테스트 등이 여기에 해당된다.
  • 일반적으로 취약하며 통합 테스트와 같이 신뢰할 수 없는 외부 종속성이 있을 수 있다.
  • 실제 사용자가 가상 디바이스가 아닌 실제 디바이스에서 문제를 보고하기 때문에 실제 디바이스가 최종 사용자의 스마트폰에 있는 애플리케이션과 더 유사해야 한다.

피라미드 테스트 중에는 실제 사용자 행동을 시뮬레이션하는 것이 중요하다. 앱 충돌, 통화/문자 중단, 네트워크 지연, 스로틀링 등 다양한 설정에서 앱을 테스트하여 실제 환경에서 앱이 어떻게 작동할지 확인할 수 있다.

What are the benefits of the test automation pyramid?

  1. 시간 및 비용 절감
  2. 정확성을 위해 인적 실수 제거
  3. 소프트웨어 요구 사항을 충족하기 위해 응용 프로그램 테스트를 재사용, 반복 및 확장할 수 있는 기능

5 reasons why testing code is great

1. 디버깅 시간을 절약할 수 있다.
테스트를 통과하는 코드를 작성할 때까지 목록에 있는 작업을 완료할 수 없다.
2. 코드 작성 전 코드에 대해 생각할 수 있게 해준다.
각 단위 테스트를 작성해야하므로 기능이 무엇을 하는지 이해해야 한다. 사용자의 요구사항에서 얻은 대부분의 모호성을 제거한다.
예 : 어떤 변수가 있을지? 특정 방식을로 코드를 작성하는 이유는 무엇인지? 등
3. 처음부터 효율적인 코드를 작성하게 한다.
게으른 코드 작성을 중단시키게 한다. 테스트를 실패하고 항상 코드를 리팩토링해야하는 과정에 지칠 것이기 때문. 즉, 첫 번째 코드가 상대적으로 효율적이고 디버깅 시간을 모두 거칠 필요가 없고 가독성이 좋은 코드를 갖게 되는 것.
4. 요구사항에 대한 문서화
단위 테스트는 사용자의 요구 사항을 설명하는 작은 코드 조각이다. 시간이 지남에 따라 유닛이 점점 추가되면 전체 앱이 작동하는 방식을 보여주는 것이나 다름없다, 이것은 다른 개발자가 프로젝트 참여시 각 유닛이 수행하는 작업과 이유를 확인할 수 있음. 변경 사항으로 인한 기능 손상을 방지할 수 있는 것.
5. 원활한 배포
앱 기능에 대한 테스트를 작성했기 때문에 단위 테스트와 통합 테스트를 모두 사용하여 배포하기 전에 마지막 순간의 문제를 포착할 수 있다. 제일 중요한 건 문제가 무엇인지 알고 있다고 말할 수 있는 것!


4개의 댓글

comment-user-thumbnail
2023년 7월 31일

유익한 글이었습니다.

1개의 답글
comment-user-thumbnail
2023년 7월 31일

크으.. 역시 Nami님!! 이젠 테스트 코드마저 정복하시는군요! 짱짱맨!!
이거 진짜 좋은 개발 습관인데, 좋은 나무는 떡잎부터 다릅니다! 화이팅!

1개의 답글