UnitTest - Swift Mocking

[hcn1519]

• https://blog.pragmaticengineer.com/swift-the-only-modern-language-with-no-mocking-framework/
• https://sites.google.com/site/unclebobconsultingllc/blogs-by-robert-martin/mocking-mocking-and-testing-outcomes
• https://blog.cleancoder.com/uncle-bob/2014/05/10/WhenToMock.html

[hcn1519]

When to mock

https://blog.cleancoder.com/uncle-bob/2014/05/10/WhenToMock.html

Mock이 없다면?

• Test suite의 실행 속도가 매우 느리다. 테스트는 서버, 데이터베이스 등을 여러번 조회하면서 테스트를 수행할 것이고, 이는 매우 느리다.
• Test coverage가 낮을 가능성이 높다.
  • 에러나 예외 상태를 만들어서 테스트할 수 없다.
  • 파일 삭제, DB 갱신과 같은 위험한 작업을 안전하게 테스트하기 어렵다.
  • 모든 상태에 대한 검증이 어렵다.
• 테스트가 실제 테스트하는 부분과 연관이 없는 곳에서 발생하는 시스템 문제에 취약하다.
  • 네트워크 타이밍 이슈
  • 예상하지 못 한 DB의 row 공백
  • Configuration 파일의 변경
  • 예상하지 못한 메모리의 점유

모든 테스트에 Mock을 쓴다면?

• reflection에 의존하는 mocking은 속도가 느리다.
• Mocking된 객체는 Mocking된 다른 객체를 리턴하는 현상으로 인해 테스트와 관련된 모든 데이터를 Mocking해야 하는 상황에 놓이게 된다.
  • Setup 코드가 매우 복잡해진다.
  • Mocking된 객체의 구조가 구현의 상세내용과 커플링이 생기게 되고, 이는 상세 내용의 변경이 많은 다른 테스트에 영향을 줄 수 있게 된다.
• 오로지 Mocking만을 위한 인터페이스를 매우 많이 정의해야 하는 상황이 발생한다. 이는 Design Damage이다.

언제 mocking해야 하는가?

Mock across architecturally significant boundaries, but not within those boundaries.

• Ex) Database, 웹 서버, 외부 서비스를 mock out하라

  • 외부 리소스를 접근하지 않으므로 빠르다.
  • 테스트를 유연하게 만들 수 있다.
  • 실패 시나리오를 테스트하기 쉽다.
  • Mock이 Mock을 리턴하는 구조를 만들지 않을 수 있다.

• 이는 자신이 개발하는 영역에서 중요한 아키텍처 관점에서의 boundaries가 어디인지 고민하게 만든다. 이러한 고민은 구분점 사이의 boundaries에서 의존성을 관리하게 만들고, 이를 독립적인 컴포넌트로 동작하게끔 만든다.

Write your own Mocks

• Mocking 툴은 강력한 기능을 제공하지만, 대부분은 쓰이지 않는다.
• 대부분의 Mocking 툴은 domain specific language를 알아야 하는 경우가 많고, 이는 비용이다.
• architectural boundaries에서 Mocking을 수행하는 것은 쉽다.
• 직접 작성한 Mock들이 재사용에 유리하다.
• 직접 작성한 Mock은 작성자가 구조를 정의힐 수 있다.
• 직접 작성한 Mock은 reflection을 사용하지 않으므로 빠르다.