수업 수업: 파트 3-19
구현하고 싶은 기능이 있을 때 어디까지 테스트 케이스를 작성해야 하는지에 대한 고민은 언제나 좋다.
“이것이 맞는지, 왜 필요한지, 왜 필요한가?”라는 질문을 끊임없이 하면 좋은 성장의 비등이 된다.
테스트 유형
1. 유닛 테스트(Unit testing)
- 하나 모듈, 컴포넌트, 클래스가 예상대로 작동하는지 테스트합니다.
- 타겟 컴퍼넌트에 의존하는 일부의 타겟은, 넥 오브젝트를 사용해 쾌적한 테스트 환경을 구축할 수가 있습니다.
- 개발자가 쓴다.
- 자동화된 시험을 한다.
2. 통합 테스트(Intergration testing)
- 둘 이상의 모듈이 잘 연동, 연결되어 있는지 테스트합니다.
→ 모듈간에 발생하는 오류를 확인합니다.
- 예를 들어, 3rd party API를 호출하면 어떤 응답이 예상되는지 테스트합니다.
- 예를 들어, 3rd party API를 호출하면 어떤 응답이 예상되는지 테스트합니다.
- 개발자가 쓴다.
- 자동화된 시험을 한다.
3. E2E 테스트(End-to-end testing)
- 실제 사용자가 사용하는 환경과 가능한 한 비슷합니다.
작성 사용자의 경험을 전체적으로 테스트한다.
- 사용자의 위치에서 체계가 정확하게 기능을 제공하는지 시험하는 것이 목적이다.
- 예제 시나리오: 사용자가 그룹 만들기 버튼을 클릭하면 해당 페이지로 리디렉션됩니다.
- 예제 시나리오: 사용자가 그룹 만들기 버튼을 클릭하면 해당 페이지로 리디렉션됩니다.
- QA 조직이 별도로 있는 경우 개발자가 아닌 QA 전문가가 작성한다.
- 자동화된 시험을 한다.
4. 인수 테스트(Acceptance testing)
- 시스템이 주어진 요구 사항을 충족하는지 테스트합니다.
- 사람이 수동으로 테스트합니다.
(자동화 X)
테스트 작성 순서
단위 테스트 👉 통합 테스트 👉 E2E 테스트
: 작은 단위에서 큰 단위로 작성을 한다.
의미있는 테스트 작성
프런트 엔드에서 의미있는 테스트는?
: 사용자가 소프트웨어를 사용하는 방법을 테스트합니다.
즉 기능에 대한 테스트를 한다.
예제 시나리오 “A 버튼을 누르면 사용자 이름과 휴대폰 번호를 입력할 수 있는 입력 창이 표시됩니다.
”컴포넌트가 화면에 어떻게 렌더링되는지, 컴포넌트 조합이 잘 작동하는지 테스트는 의미가 없습니다.
→가변적이기 때문이다.
(기획, 디자인 요건에 따라 쉽게 바꿀 수 있는 부분이다.
)
반드시 테스트해야 할 사항
- 모든 사용자 요구사항은 테스트 케이스로 처리됩니까?
- 백엔드 인터페이스를 테스트할 때 잘못된 입력을 입력할 때 예상되는 응답을 반환합니까? (오류 코드 대 Exception을 throw)
- 프런트 엔드에서 사용자가 사용 기능이 작동합니까?
- 기능 테스트에 중점을 둡니다.
- 페이지에 중요한 버튼이 렌더링됩니까?
- 그 버튼을 클릭하면 의도대로 작동합니까?
- 기능 테스트에 중점을 둡니다.
테스트할 필요가 없는 것
- 모든 라인을 반드시 테스트할 필요는 없습니다.
- 페이지가 반응형 웹인지 여부를 테스트할 필요가 없습니다.
- PC에서는 버튼이 화면 중앙에, 모바일에서는 버튼 위치가 화면 하단에 있어야 합니다.
→ 테스트할 필요 없음
- PC에서는 버튼이 화면 중앙에, 모바일에서는 버튼 위치가 화면 하단에 있어야 합니다.
이 게시물은 첫 캠퍼스 환불 챌린지 참여를 위해 작성되었습니다.
첫 캠퍼스 링크