실용주의 프론트엔드 개발 리뷰 Part.4

실용주의 프론트엔드 개발을 읽고 느낀점을 써봤습니다.

1. 테스트를 해야하는 이유

• 무조건 많은 테스트도 좋은게 아니다.

  • 테스트를 짜는 목적을 기억해야 한다.
  • 이전에 읽었던 “소프트웨어 장인”책 내용중, 테스트 커버리지에 목매이다가 중요한 것을 놓치거나, 다 된 기능 위에서 단순히 커버리지 퍼센트만 맞추려는 작업은 어리석은 일이다. 내용이 떠올랐다.

• 핵심기능, 핵심 코드에 대한 검증

  • 나중에 누군가가 수정하더라도, 테스트를 보고 이전 의도를 파악할 수 있어야 한다.
  • 리팩토링을 하더라도, 이전처럼 똑같이 돌아갈 수 있게 확인하는 검증 수단이라 생각한다.

2. 테스트코드도 이해하기 쉽게

• TDD 와 BDD

  • TDD
  • 테스트 주도 개발(Test Driven Development)
  • 일반적인 개발 -> 테스트 flow가 아닌, 테스트를 작성 후 테스트를 통과하기 위해 개발하는 방법
  • TDD Wiki
  • BDD
  • 행동(시나리오) 주도 개발 (Behavior Driven Development)
  • 행동에 대한 정의는, 개발자가 아닌 일반사람이 보아도 이해할 정도로 정의함.
  • 사용자 관점에서 기능별 테스트를 하면서, 개발 코드가 바뀌어도 테스트코드가 바뀌지 않는다.
  • BDD (Behaviour-Driven Development)에 대한 간략한 정리

3. 명세기반 테스트 기법 종류

• 동등분할

  • 테스트 대상 데이터의 구간을 일정하게 나누어서 케이스 구성.

• 경계값분석

  • 분기 또는 반복 구문의 경계값을 기준으로 케이스를 구성.

• 결정테이블

  • 조건과 행위에 따른 결과를 테스트하기 위해 구성

• 조합

  • 테스트하는데 필요한 값이 다른 값과 조합을 해서 구성.

• 상태전이

  • 특정 값을 변하게 함으로써, 다른 쪽의 상태가 변경되었는지 테스트

• 테스트는 요즘들어 정말 필요하다 느끼고 있다. 어느 한 쪽 기능 개발을 해놓았는데, 다른사람이 건들다가 안된다던지…

  • 특히 해당 내용이 CS로 인입되서 처리해달라는 요청 들어오면 참.. ㅜㅜ
• 개인적으로는 BDD가 마음에 든다. 다양한 시나리오를 고민하고 테스트를 진행함으로써, 여러 변수들을 차단할 수 있고, 사용자 경험에 대해 좀 더 고민해 볼 수 있기 때문이다. 다만 사용자가 어떻게 사용할 지 예측을 하는게 쉽지 않은만큼, GTM등 여러 다양한 툴을 이용해서 지속적인 관찰을 하고, 더 좋은 사용자 경험을 만들도록 노력해야 한다고 생각한다.
• 명세기반 테스트 기법 중, 경계값분석과 동등 분할의 차이를 아직 잘 이해하지 못하겠다. 테스트를 많이 생각해보지 않아서 그런 것일수도… 좀 더 고민해봐야지