Mockery::close() 가 예외를 발생시키면 DatabaseTransactions 트레이트가 동작하지 않음

메소드 하나만 테스트 돌렸을 땐 통과되던게, 파일을 통으로 돌리니까 에러가 나더군요.

에러가 나는 원인을 보니, 데이터베이스에서 락이 걸렸기 때문이었습니다.

DatabaseTransactions 트레이트를 쓰고 있어서, 이전 테스트가 다음 테스트에 영향을 줄 이유가 전혀 없어보이는데, 대체 락이 왜 걸릴까? 찾다보니 원인은 Mockery 때문이었습니다. 이 링크 덕분에 알게 됐어요.  이 글 없었으면 며칠 날릴뻔 했네요. 소중한 정보 공유해준 얼굴 모를 개발자에게 오늘도 감사를!

Mockery를 쓰려고 했다가 필요 없어져서 테스트 코드에서는 Mockery 쓰는 부분을 다 제거했는데, 종료하는 코드를 남겨뒀더라구요.

public function tearDown() {
    Mockery::close();
}

종료할 Mockery가 없는데 종료를 해서 예외가 발생했었나봅니다. Mockery가 예외를 발생시키면, 트랜젝션이 롤백되지 않은채로 테스트가 멈추기 때문에 락이 걸린 채로 다음 테스트가 실행되나 봅니다.

위 코드를 제거하고 돌리니 잘 되네요.

오늘의 삽질 로그 끝

익혀야할 것

오늘 업무를 종료하며 내일은 아래 두 가지를 익혀야겠다고 생각했습니다.

  1. Laravel HTTP 테스트에서 Mockery를 사용하는 방법
  2. Laravel HTTP 테스트 실행시 xdebug 로 디버깅하는 방법

오늘은 테스트를 작성하면서 삽질을 많이했는데, 첫번째 것은 오늘 삽질 결과 알아낸 해결책이고, 두번째 것은 오늘과 같은 삽질을 덜 고통스럽게 하는 해결책입니다.

테스트하기 어려운 코드라는 6가지 신호

최근에 의존성 주입을 알게되어서 (신나서?) 마구마구 의존성을 주입하다보니 한 클래스를 생성하는데에 너무 많은 의존성을 주입하는 경우가 생기더군요. 가장 많은 건 13개까지… 그래서 과연 내가 잘하고 있는 것이 맞나 싶어 궁금해하고 있었는데, 오랜만에 들춰본 Laravel Testing Decoded 에서 명쾌하게 ‘아니다’ 라고 얘기해주고 있네요. 참고가 되실까 싶어 책의 내용을 일부 공유해봅니다.

테스트하기 여려운 코드라는 6가지 신호

  1. New Operators
    • 클래스 내부에서 다른 클래스를 생성하는 경우.
  2. Control-Freak Constructors
    • 생성자에서 의존성 주입 역할 이외에 다른 행위을 하는 경우.
  3. And, And, And
    • 클래스가 단일책임원칙을 지키지 않는 경우.
  4. Too Many Paths? Polymorphism to the Rescue!
    • switch 문이 있다면 더 작은 클래스들로 쪼개는 편이 테스트하기 쉬워진다.
  5. Too Many Dependencies
    • 의존성이 너무 많은 경우.(4개 이상이면 리팩토링이 필요하다고 합니다)
  6. Too Many Bugs

책에 다음과 같은 구절도 있으니, 앞으로는 어떻게 하면 의존성과 파라미터 사용을 줄일 수 있을지도 더 생각하면서 코딩해 버릇해야 겠습니다.

“Each time that you remove a dependency or parameter, you’re improving the code.”

JeffreyWay. ‘Laravel Testing Decoded.’

 

leaderboard-728x90