Skip to content

Study6.md

Latest commit

 

History

History
69 lines (50 loc) · 3.5 KB

Study6.md

File metadata and controls

69 lines (50 loc) · 3.5 KB

6차 Rust 스터디

과제 리뷰

챕터 11. 테스팅

11.1. 테스트 작성하기

  1. 필요한 데이터 혹은 상태를 설정하기
  2. 우리가 테스트하고 싶은 코드를 실행하기
  3. 그 결과가 우리 예상대로인지 단언하기(assert)
  • 함수를 테스트 함수로 변경하기 위해서는, fn 전 라인에 #[test] 어노테이션을 추가
assert!() // 매크로는 true라면 통과, false라면 panic!
assert_eq!() // 동일할 때 pass 
assert_ne!() // 다를때 pass
  • assert_eq!와 assert_ne! 매크로를 사용하기 위해서는 partialEq와 Debug 트레잇이 구현되어 있어야 한다.

  • 커스텀 실패 메세지 추가: assert!(bool, message)

  • [should_panic]: 실제로 패닉이 발생하는지를 확인할 때 사용

  • #[should_panic(expected = "test message")]: should_panic 속성에 추가한 expected 파라미터를 활용하여 패닉 테스트가 사용자 본인이 예측한 패닉이 발생한 것인지 제한적인 패닉 테스트가 가능합니다.

11.2. 테스트 실행하기

  • 기본적으로 테스트는 병렬 진행하므로 서로 다른 테스트가 공유 데이터를 갖는 경우 문제가 발생할 수 있음.

  • 테스트를 병렬적으로 실행하고 싶지 않은 경우 cargo test -- --test-threads=1

  • 테스트 통과 시 표준 출력으로 출력되는 내용을 캡쳐해 터미널에서 확인할 수 없게된다, cargo test -- --nocapture 플래그를 사용해서 캡쳐를 비활성화해 터미널에서 확인할 수 있다.

이름으로 테스트의 일부분만 실행하기

  • 단일 테스트 : cargo test (함수 이름)
  • 여러개의 테스트 : cargo test add (함수 이름에 add가 포함된 함수 모두 테스트)
  • 특별한 요청이 없는 경우 무시하기 : #[ignore]

11.3. 테스트 조직화

  • 테스트는 크게 단위 테스트, 통합 테스트로 분류할 수 있다.

단위 테스트

  • 각 코드의 단위를 나머지 부분과 분리하여 테스트
  • private 함수도 별 문제없이 테스트가 가능하다.

통합 테스트

  • 통합 테스트 - 라이브러리의 수많은 파트들이 함께 올바르게 동작하는지를 시험
  • 프로젝트 최상위 디렉토리에 tests 디렉토리를 생성하면 알아서 테스트용 파일로 파악한다.
  • 그 내부 파일은 #[cfg(test)]를 이용한 어노테이션을 해줄 필요가 없다.
  • 통합 테스트는 바이너리상에서 불가하기 때문에 이를 위해 라이브러리 크레이트로 먼저 테스트할 수 있음.

다음 회차 범위

회고

  • 이지한: 테스트 사용을 많이 해봐야 할 것 같습니다~
  • 허신: 언어에서 테스트 지원 되는 게 너무 좋은 것 같아요
  • 정연집: 테스트 잘 활용하면 편할 것 같아요...
  • 유병조: 언어 차원에서 테스트 지원이 잘되서 좋은 것 같아요~
  • 이명수: Rust in Action 사서 봐야겠네요 ㅎ
  • 김기덕: should_panic에 expected 파라미터를 잘 활용하면 좋을 것 같네요!
  • 이재현: 테스트 작성이 꽤 작성하기 좋게 되어있는 것 같아서 써먹어보고 싶네요