Day07

제품을 만들거나, 미션을 해결하기 위해서 개발을 진행할 때 한번에 모든 요구사항을 파악한 후에, 요구사항에 맞게 완벽하게 설계하고, 모든것이 담겨있는 설계를 빈틈없이 구현해내어서 완벽한 결과를 짠~ 하고 만들어 낼 수 있으면 얼마나 좋을까?😁😁 이렇게 개발을 진행하는 것은 아무리 간단한 문제라도 누구에게나 쉽지 않을 것이다. 그렇기 때문에, 많은 개발자들은 큰 전체를 작은 부분으로 나누어서 "설계 - 개발 - 검증" 단계를 반복해서 진행하면서 큰 전체를 조금씩 완성해가는 방법을 많이 사용하고 있다.

 

이때 `검증` 단계에서 어떻게 자신이 만든 기능을 믿고 다음 단계로 나아갈 수 있을까? 적은 양의 함수라면 직접 다 실행하면서 개발을 진행하면 될것이다. 하지만, 함수와 클래스가 많아질 수록 사람이 직접 모든 함수를 호출해보고 검증한 후에 넘어가기 위해서는 너무 많은 시간이 필요해진다. 이때 필요한 것이 함수의 기능을 검사해줄 수 있는 테스트 코드이다. 즉, 함수를 검증하기 위한 함수를 작성한다. 그리고 이것을 소프트웨어 테스트 라고 한다. 이처럼 중요하게 여겨지는 다양한 테스트에 대한 개념과 테스트를 활용한 개발 방법에 대해서 정리해 보고자 한다.

 

Software Test

구현한 기능, 코드, 함수, 시스템 등이 의도한대로 동작하는지 검증하는 과정

 

테스트 코드가 필요한 이유

• 빠르게 테스트를 실행할 수 있다.
• 재사용이 편리하다.
• 문서로서의 기능을 할 수 있다.
• 사이드 이펙트 파악이 쉽다

👉 사이드 이펙트 : 기능 수정으로 인해서 이전에 있던 어떤 기능에 영향을 주는지 확인한다.

테스트 종류

단위 테스트 (Unit Test)

• 최소 단위인 ‘모듈(Module)’의 동작을 검증한다.
  • 대부분의 함수를 테스트한다.
• 클래스 하나, 함수 하나와 같이 작은 부분에 대한 테스트
• 최대한 간단하고, 디버깅이 쉽도록 만들어서 테스트한다.

단위 테스트의 특징

• 빠르게 수행하고 (quickly)
• 격리된 방식으로 (isolation)
• 작은 코드 조각(단위)을 검증하고 (veridate)
• 자동화된 (automatic) 진짜 코드

👉 화이트박스 테스트(White-box Test)
      소프트웨어 내부 구조나 구현 방식을 고려해 테스트한다.

통합 테스트 (Integration Test)

• 모듈을 통합하는 과정에서, 각 모듈 간의 인터페이스와 관련된 결함이 있는지 검증한다.
• 여러 모듈 간 의도대로 협력하는 지에 대한 테스트
• 비교적 단위 테스트보다 복잡하고 시간이 많이 소요
  • 관련 모듈 설정 등을 포함하기 때문이다.

하향식 통합 (Top Down)
최상위 모듈부터 점차 하위 모듈 방향으로 통합하면서 테스트
⇒ 아직 통합하지 않은 하위 모듈의 입출력을 대신해줄 Stub이 필요하다.

상향식 통합(Bottom Up)
최하위 모듈부터 점차 상위 모듈 방향으로 통합하면서 테스트
⇒ 상위 모듈을 대신해서 호출을 해줄 Driver 가 필요하다.

동시식 통합(Big Bang)
모든 모듈을 한꺼번에 통합한 후에 테스트
⇒ 오류 발생 시 결함 원인을 찾기 어렵고, 통합 시간이 오래걸린다.

연쇄식 통합(Threads)
중요 모듈을 먼저 구현하고 통합한 후에, 보조적인 모듈들을 점차 구현 후에 통합하는 방식
⇒ 핵심 로직에 대해 빠른 테스트가 가능하다.

시스템 테스트(System Test)

• 소프트웨어와 하드웨어를 결합 한 뒤에 수행하는 검증
• 통합 테스트 보다 더 큰 개념이며, 전체 시스템에 대한 동작을 테스트한다.
• 전체 시스템의 성능에 집중해서 검증한다.
  • 시스템이 버티는 과부하 한계점
  • 작업속도
  • 복구 및 회복작업
  • 보안 안전 테스트 등

인수 테스트(Acceptance Test)

• 사용자 관점에서 소프트웨어가 요구사항을 충족하는지 검증한다.
• 직접 사용하는 고객이 만족할 수 있는지 테스트한다.
• 소프트웨어에는 오류가 없더라도, 요구사항을 충족시키지 못할 경우에 테스트는 실패한다.
  • 기능이 미흡 할 때
  • 성능이 미달 일 때

👉 알파 시험(Alpha Test)
      사용자를 개발자 환경으로 초대해서 진행하는 테스트

👉 베타 시험(Beta Test)
      다수의 사용자들이 각자의 환경에서 진행하는 테스트

UI 테스트 (UI Test)

• FE, mobile 분야에서 UI 기능 단위로 진행하는 테스트
• 단위 테스트(Unit Test)와 시스템 테스트(System Test)의 사이

E2E test

• End-to-End 테스트
• 2가지 기준으로 해석된다.
  • 전체의 시스템 관점에서의 테스트
  • UI 테스트(UI Test)와 비슷한 테스트

---

테스트를 활용한 개발 방법론

`소프트웨어 개발 방법론`이란 소프트웨어를 개발하기 위한 '구체적인 절차, 방법, 기술 등을 정리'한 것이다. 이를 통해서 개발자들이 프로젝트를 효율적으로 관리하고 소프트웨어를 더욱 품질 높게 개발할 수 있게 도와준다. 그중에서 "테스트"를 중심적으로 사용해서 개발을 진행하는 과정을 명시하는 개발 방법론에 대해서 정리했다.

 

TDD(Test-Driven-Development)

https://medium.com/@luisfmachado/swift-test-driven-development-tdd-810add46a1b9

• 테스트 주도 개발 방법론
• 코드를 작성하기 전에 요구사항에 맞게 테스트 케이스를 작성하고, 이 테스트를 통과하기 위한 코드를 작성해서 기능을 구현한다.
• 테스트에 실패한 코드는 수정하면서 반복적인 테스트를 통해서 개발을 진행한다.

💡 테스트 케이스
   - 특정 기능 또는 시나리오를 테스트하기 위한 지침이 포함된 문서
   - 테스트를 수행하는 데 필요한 모든 정보를 제공한다.
   - 테스트의 목적, 입력 데이터, 예상 결과 등을 명확하게 정의한다.

TDD의 장점

• 품질 향상
  • 테스트케이스로 지속적으로 테스트하면서 코드의 정확성을 검증할 수 있다.
  • 많은 테스트 진행으로 더 정확하고 안정적인 코드를 작성 할 수 있다.
• 리팩토링 지원
  • TDD는 코드를 작은 단위로 분리하고 테스트 가능한 형태로 작성하는 것을 장려한다.
  • 작은 단위로 분리하기 때문에 코드의 구조와 설계를 개선하기 쉬워진다.
• 빠른 피드백
  • TDD를 사용하면 작은 단위의 테스트를 빠르게 실행하고 결과를 확인 할 수 있다.
  • 이를 통해 버그를 빠르게 발견하고 수정할 수 있다.
• 협업 강화
  • TDD는 테스트 코드가 개발 프로세스의 일부로써 문서화된다.
  • 테스트가 문서화 되기 때문에 협업중인 개발자가 똑같은 기준을 명확하게 가지고 개발을 진행하게 되고, 이를 통해서 로직의 이해와 검증이 구체적이게 되고, 의사소통과 협업을 강화시킨다.

BDD(Behavior Driven Development)

https://katalon.com/resources-center/blog/bdd-testing

• 행동 주도 개발 방법론
• TDD에서 파생된 개발방법론으로 TDD에서 기능 중심의 '테스트케이스'를 작성하는데 한계를 극복하기 위해 등장하게 되었다.
• ‘사용자의 행위’를 정의하고 행위에 따라 개발해 나아간다.
  • ‘사용자의 행위’는 기획자가 작성한 ‘요구사항’이나 ‘기획서’에 적혀 있는 내용 자체를 의미한다.
• 테스트케이스를 작성하기전에 비즈니스 요구사항이나 기능 요구사항을 이해하고 분석하여 사용자의 행동을 중심으로 한 '시나리오를 작성' 한다.
  • 도메인 특정 언어를 사용하여 비개발자도 이해할 수 있는 방식으로 시나리오를 명세화한다.
• 작성된 시나리오를 기반으로, 사용자의 행동을 중심으로 테스트 케이스를 작성한다.
  • 이후에는 TDD와 비슷한 방법으로 과정이 진행된다.

💡 테스트 시나리오
원하는 기능이 어떻게 동작해야 하는지를 명세하는 것
개발자가 작성한다.

👉 Given(주어진 환경)
‘사용자 행위’를 수행하기 위해 주어진 ‘환경’

👉 When(행위)
실제 사용자의 행위

👉 Then(기대결과)
행위에 따른 기대결과

예시)
“사용자가 페이지에 접속해 있는 상황에서(Given)”
“사용자 아이디 필드에 ‘adjh54’을 입력하고 비밀번호 필드에 ‘12345’를 입력하고 ‘로그인’ 버튼을 누르면(When)”, “로그인이 성공하고 메인 페이지로 이동한다(Then)”

 

TDD VS BDD

테스트케이스

• TDD : 기능을 확인하기 위한 목적으로 작성한다.
• BDD : 시나리오를 주체로 한 행위를 확인하기 위한 관점에서 작성한다.

상호 보완적

• TDD : BDD에서 보기 어려운 TDD 테스트 케이스를 통해 모듈들을 테스트 커버리지를 극복한다.
• BDD : TDD에서 보기 어려운 ‘유저 시나리오’ 관점으로 확인할 수 있다.

 

💡 TDD와 BDD 각자의 장점과 특징을 알고 목적에 따라서 진행하려는 개발 과정에서 적합한 개발 방법론인지를 판단하고, 사용여부를 결정해야한다.

 

 

참고

https://adjh54.tistory.com/305

[개발방법론] TDD, BDD 이해하기-1 : 정의 및 수행과정