테스트 코드?

Test Code?

테스트… 나에 대한 인내심 테스트인가.

 

테스트에 대해서 먼저 알아보도록 하자.

소프트웨어 테스트란 무엇인가요? | IBM

소프트웨어 테스트란 무엇인가요? | IBM

 

소프트웨어 개발 테스트

소프트웨어 개발 테스트

 

[위의 2개의 사이트를 참고하였다]

• 우선 소프트웨어 테스트란 뭘까?→ 역시 개발자는 귀찮은 거는 못 참는 거 같다.
• 소프트웨어 테스트는 소프트웨어 제품이나 애플리케이션이 올바르게 작동하고 있는지 평가하고 검증하는 프로세스입니다. 잘 수행된 테스트는 버그 방지와 성능 개선 등의 이점을 제공합니다.
• 음… 그러면 “평가, 검증 프로세스” 라고 이해를 해보자.
• IBM 공식문서엔 여러가지 테스트 철학이 나와있다 (Shift-left, Shift-right…)
  • “지속적인 테스트는 모든 부분이 배포될 때까지 기다렸다가 테스트를 시작할 필요가 없다는 뜻”
  • “테스트 전략과 관리 계획을 이해하면 필요한 배포 속도를 지원하기 위해 테스트의 모든 측면을 자동화하는 것이 필수적”

 

→ 아하..!

 

• 역시 개발자는 [자동화]를 참 좋아하는 것 같다.
• 처음 테스트를 들었을 때, 그냥 디버깅하면 될듯..;; 이라고 생각을 했었는데, 자동화의 큰 이점이 있구나!

 

[”어 그러면 테스트는 어플 전체로 하는 건지..?”]

[”물론 걱정하지마.. 다양한 유형이 있단다”]

• 소프트웨어 테스트 유형은 아래와 같이 존재한다.
  • 승인 테스트, 코드 검토, 통합 테스트, 단위 테스트 … etc
  • 각각의 테스트들은 특정한 목표와 전략을 가지고 있다.

---

이에 대해 자세히 알아보기 전 소프트웨어 테스트는 왜 중요할까?

• 품질 관리의 필요성 때문에
  • 오류나면.. 뒷감당하기 무섭잖아..
• 개발 및 지원 비용을 절감
  • 테스트 피드백을 빨리 받을수록 다음과 같은 문제를 더 신속하게 해결할 수 있음

자 학습 내용으로 다시 되돌아와보자.

• 네이버 부스트 캠프 챌린지 때 정리를 했었지만 다시 알아보자.

커~다란 V 글자가 있다.

• 이 커다란 V는 뭘까?
  • “진짜 말그대로 소프트웨어 개발 방법론 중 V-Model 이다”
• V-Model?
  • 소프트웨어 개발 시 분석 - 디자인 - 구현 - 테스트 - 배포 - 유지보수 방향으로 테스트를 진행하는 모델
  • :: 더 나은 서비스로 고도화
  • 여기서 나온 Unit Test, Integration Test, System Test, Acceptance Test는 뭐지?
  • 하나씩 알아보자

1. Unit Test
   • 단위 테스트라고 불린다.
   • 소프트웨어의 최소단위, 보통 함수를 가리킨다.
   • 하나의 모듈을 기준으로 ‘독립적으로 진행되는 가장 작은 단위의 테스트’
     • 위의 설명처럼 보통 메서드 레벨(기능 단위)를 테스트하는데 사용
   • 특징?
     • 즉각적인 피드백이 나옴
     • 간단, 디버깅 Easy, 실행 빠름 → 프로그램의 가장 작은 빌딩 블록이라고 생각
     • 이들을 결합한 버전이 잘 ~ 될지는 모른다.
2. Integration Test
   • 통합 테스트라고도 불린다.
   • Unit Test 이후 Unit들을 결합 → 결과 조합이 올바르게 작동하는지 테스트
3. System Test
   • 시스템 테스트
   • Integration Test가 완료된 후 완전한 시스템에 대해 수행하는 테스트
     • 시스템의 기능 측면에서 뿐만 아니라, 비기능적(사용성, 견고성, 신뢰성, 보안성, 성능)인 요구사항도 만족되는지를 검증
4. Acceptance Test
   • 알파 테스트
     • 회사 내의 다른 사용자에게, 또는 실제로 인수받을 사용자에게.. 테스트를 진행하도록 함
     • 실시간으로 오류, 문제 파악 → 바로바로 수정 가능한 테스트 방식 중 하나
   • 베타 테스트
     • 일부 사용자들에게 배포하여 직접 사용 → 사용자들로부터 피드백을 받아 사용성을 파악

챌린지 과정에서도... 서칭을 하는 과정에서, 또 얼마전 읽어본 책에서 TDD라는 것이 있었다.

서칭을 하다보니 TDD(Test Driven Development)라는 게 있는데… 이건 또 뭘까?

실전에서 TDD하기 | 카카오페이 기술 블로그

실전에서 TDD하기 | 카카오페이 기술 블로그

 

[iOS - swift] TDD (Test Driven Development)

[iOS - swift] TDD (Test Driven Development)

 

• 그래서 TDD가 뭔데?
  • 컴파일조차 되지 않는 코드를 대상으로 먼저 테스트를 작성하고, 그다음 테스트코드가 컴파일되고 실행까지 되도록 코드를 작성한 후 테스트가 통과되면 테스트의 보호아래 코드를 다듬는 것
  • 세 가지 단계를 한 사이클로 돌게 된다.
    • 테스트를 작성한다(빨간 막대)
    • 실행 가능하게 만든다(초록 막대)
    • 올바르게 만든다.
  • [코드 작성 → 컴파일]
• 지루함 반대에는 내가 생각한 대로 코드가 동작한다는 확신을 얻을 수 있다.

오호… 기존 하드 코딩을 한 뒤 print문, lldb로 디버깅을 통해 전체 프로그램을 확인했었는데…

 

하지만 보기만해도 그렇듯 대입하기가 참 어렵다고 한다.

 

(설계도를 펴놓고 시작하는 것과 마찬가지)

---

참고 링크

[iOS - swift] Unit test 개념, @testable

[iOS - swift] Unit test 개념, @testable

 

유닛 테스트란? - 유닛 테스트에 대한 설명 - AWS

유닛 테스트란? - 유닛 테스트에 대한 설명 - AWS

 

---

이제 이를 어떻게, 실제 상황에서 사용할 수 있을까?

당장에 네이밍은 어떻게..?

뭐~ 네이밍도~?

Test Code 제목 작성 팁

• 책의 목차를 쓰듯 테스트 코드를 작성
  • 제목만으로도 어떤 테스트인지 알 수 있어야 함 → 한글로 작성을 하자(In Korea..)
• 분류별로 나눠서 작성하기
  • 제목과 연관된 점을 분류별로 나누기.

 

---

코드 리뷰를 하는 과정에서, 많은 분들이 Given-When-Then 방식을 통해 Test-Code를 체계화하는 것을 알 수 있었다.

나도 모르고 그냥 쓰긴 했는데, 이건 무엇을 기준으로 나누는 걸까?

 

Given-When-Then?

• Given: 테스트 코드를 작성하기 위해 필요한 변수를 선언하는 준비 과정
• When: 테스트에 필요한 준비물(변수)을 가지고 이를 수행하려는 대상(함수)을 테스트하는 과정
• Then: 수행한 테스트에 대한 결과를 확인하는 과정

추가적인 팁으로는...

테스트 데이터는 난수를 만들어 사용하기

• remove(1)과 같은 직접 적인 변수 선언 & 초기화 후 대입이 아닌
• Int.random(1..<10) 이와 같은 랜덤값을 remove() 안에다 넣어주는 게 테스트의 목적으로서 적절하다.

---

[마스터 클래스를 들으면서 처음 들어봤던 내용에 대한 간단한 정리를 할 예정]

SUT: System Under test, 테스트에서 검증하려는 대상

블랙박스 테스트?

테스트 기법 (화이트박스 / 블랙박스)

테스트 기법 (화이트박스 / 블랙박스)

 

• SW가 수행할 특정 기능을 알기 위해 각 기능이 완전히 작동되는 것을 입증하는 테스트→ 입력값, 출력값만을 확인하는 테스트
• [기능 테스트] 라고도 함.
• 종류
  1. 동치분할검사 (Equvialence Partitioning)
  2. 원인-효과 그래프 검사 (Cause and Effect Graphing)
  3. 오류 예측 검사 (Error Forecast)
  4. 비교검사 (Comparison Testing)
  5. 경계값 분석 (Boundary Value Analysis)

테스트 더블(Test Double)?

• 실제 객체 대신에 테스트를 위해 사용되는 가짜 객체들을 총칭하는 말

1. Mocks (모의 객체)
   • 특정 함수의 동작을 확인하는데 사용
   • 특정 메서드가 호출되었는지, 호출되었다면 어떤 인자와 함꼐 호출되었는지 등을 검증할 수 있음

 2. Stubs

• 미리 정의된 동작을 하는 특별한 fake 객체
• 보통 함수의 반환 값을 미리 설정해두고, 호출되었을 때 이 값을 반환
• 예시
  • 데이터베이스 호출을 스텁으로 대체하여, 데이터베이스에 연결하지 않고도 항상 동일한 데이터를 반환하도록 설정할 수 있음

---

단위 테스트 스타일

• 상태 기반 테스트
  • 비유
  • : 잔액이 5만원 있는데, 2만원 입금시 내 잔액은 7만원인가 확인
• 결과 기반 테스트
  • 비유
  • : 잔액이 5만원있는데 5만원을 송금하면 상대방에게 5만원이 있는지?
• 통신 기반 테스트
  • 객체 간의 커뮤니케이션이 올바르게 이루어졌는지?
  • = 객체 간의 메시지 교류가 올바르게 이루어졌는지?
  • 비유
  • : 5만원을 송금해서 받게되면 서로에게 알림이 뜨는지?

---

단위 테스트… 무엇을 테스트해야 하는가?

• Right - 결과가 올바른가? right?
• B - 모든 경계(boundary) 조건이 CORRECT한가?
  • CORRECT경계 조건 (boundary condition)에서 버그를 유발
    • 형식일치 (Conformance)
    • 순서 (Ordering)
    • 범위 (Range)
    • 참조 (Reference)
    • 존재성 (Existence)
    • 개체 수 (Cardinality)
    • 시간 (Time)
  • [크랙!!!!이 아님]
• I - 역(inverse) 관계를 확인할 수 있나?제곱근을 계산하는 함수를 검증할 때는 제곱해서 오차 확인 (sqrt → square)
  데이터가 데이터베이스에 잘 들어갔는지 확인 (insert → select)각각 테스트 루틴을 구현해야 함
  서로 호출하는 경우 상쇄되는 버그가 존재할 수 있음
  • ✔︎ 원래 루틴과 역루틴을 모두 만든 경우에는
  • ✔︎ 논리적인 역(inverse) 관계로 검증
• C - 다른 수단을 사용해서 결과를 교차 확인(cross-check)할 수 있나?
• E - 에러 조건(error condition)을 강제로 만들수 있나?
• P - 성능(performance) 특성이 한도내에 있나?

---

AAA 테스트?

• 구성요소
  • Arrange(준비 구절)
  • SUT 제작. 테스트 대상 메서드, 클래스에 필요한 파라미터, 인스턴스 생성을 한다.
  • Act(실행 구절)
  • SUT에서 메서드 호출. 인스턴스의 리턴 결과, 출력이 있다면 변수에 저장
  • Assert(검증 구절)
  • 결과를 검증

---

그럼 given-when-then, AAA 테스트 중 단위 테스트에선 무엇을 쓸까?

TDD, BDD란?

TDD, BDD란?

 

kotest가 있다면 TDD 묻고 BDD로 가!

 

• 단위 테스트(Unit Test)에서는 보통 AAA (Arrange-Act-Assert) 패턴이 더 자주 사용됨.
• BDD 방식을 채택하고 있거나, 테스트 케이스를 행동 시나리오로 명확히 표현하고자 한다면, Given-When-Then 패턴을 사용하는 것도 좋은 선택
  • BDD? 
  • 사용자의 행위까지 생각하고 테스트하며 개발하는 방식

TDD, BDD의 차이에 대한 사진이다.

 

 

Test Code에 대한 정리를 진행하며

무지하면 몸이 고생한다...는 생각을 계속 했던 것 같다

(print문으로만 확인해본 나 칭찬해~)

 

새로운 것을 배움으로써 한단계 성장한 느낌을 오늘도 받는다.