Let's TDD (4)

alwaysblu·2021년 5월 9일
0

출처

(Suyeol Jeon)

질문에 대한 답변

1)

xcode에서 제공하는 UI테스트는 왜 이름을 UI테스트라고 붙였는지 모르겠다고 하며
사실상 UI테스트가 아니라 통합 테스트라고 한다.
그래서 처음부터 끝까지 앱을 전부 실행시켜봐야지 그 테스트 결과를 알 수 있다고 한다.
그런데 그때의 통합테스트가 필요한 것과 유닛테스트가 필요한 것은 전혀 다른 분야라고 생각한다고 한다.
위에서 작성한 인디케이터 테스트처럼 하나의 상태에 따라서 쉽게 바뀌는 속성을 테스트하기 위해서는
UI테스트 같은 통합테스트보다 유닛테스트가 더 적합한 모델이라고 한다.
왜냐하면 이런 유닛테스트는 빠르고 작성하기 쉽기 때문에 여러가지를 작성할 수 있는데
UI테스트와 같은 통합테스트는 그에 비해 테스트 실행시간도 훨씬 길고 통합테스트를 작성하는데 걸리는 시간도 굉장히 오래걸리고 뷰 하이라키(hierarchy:계층)에 굉장히 의존적이기 때문이다.
(위와 같은 이유들 때문에 UI테스트를 하는 것을 결정하는 것이 조심스럽다고한다.)

그래서 전수열님 개인적으로나 회사에서는 UI테스트를 전혀하지 않는다고 한다.

2)

전수열님도 똑같은 고민을 했었다고 한다.
외부에서 접근하기 어려운것은 당연히 private으로 만들어서 은닉을 시키고 싶었는데
이게 막상 테스트에 가서 은닉된 뷰를 찾으려고 하면
뷰 하이라키를 전부 따라가서 해당 뷰 클래스가 있는지 없는지를 찾아내는 방법 밖에 없다고 한다.
그래서 전수열님의 트레이드 오프(교환: 은닉화의 장점을 버리고 은닉된 뷰를 찾기 어려운 단점을 고쳤다.)를 했다고 한다.
만약 은닉화하지 않아서 노출되는 것이 걱정된다면 코드 컨벤션으로도 해결할 수 있다고 한다.
private하게 사용하고 싶은 코드에 _(언더스코어)를 붙여서 외부에서 접근할 때
"언더스코어가 붙여져있는데 내가 써도 되나"라는 생각이 들게해서 해당 코드를 건들지 못하게 은닉화시키는 방법이다.

그래서 private을 사용하지 않고 코드 컨벤션으로 은닉화를 시키므로서 뷰를 찾기 쉽게 할 수 있다.

_single_leading_underscore과 같은 언더스코어로 둘러쌓인 네이밍은
주로 한 모듈 내부에서만 사용하는 private 클래스/함수/변수/메서드를 선언할 때 사용하는 컨벤션이다.

그리고 값들을 보호하기 위해서 전수열님이 쓰는 방법으로
전수열님은 스토리보드를 사용하지 않기 때문에 var를 사용하지 않고 let을 사용한다고 한다.
그래서 외부에서 속성이 바뀌는 것은 어쩔 수 없이 var를 사용하지만
새로운 값이 할당되는 것은 컴파일러가 막아주고 있다고 한다.

스토리보드 사용고 let그리고 var의 관계가 뭘까? 찾아보자

3)

어떤 클래스간의 커플링이 걸리는다는 것은 어떤 클래스끼리의 의존도(결합도)가 높은 것을 의미한다.
예를 들어 A클래스와 B클래스가 있을 때
이 두개의 클래스가 지나치게 결합도가 높아서
A클래스를 테스트 하기 위해서 B클래스가 무조건 필요한 것이
A클래스와 B클래스에 커플링이 걸린다고 한다.

그래서 이전에 한 작업이 프로토콜을 만들어서 두 클래스에 결합도가 있는 것을 풀어버린 것이다.

4)

테스트 더블의 5가지 요소간의 차이 (Dummy, Fake, Stub, Spy, Mock)

위에서 전수열님이 한 것은 stub이 아니라 spy였다고 한다.

Dummy -> Fake -> Stub -> Spy -> Mock 이렇게 단계가 있는데
한 단계씩 높아질 때마다 더 많은 역할을 수행한다.

  • Dummy는 단순히 파라미터의 값을 취하기 위한 것이다.
  • Fake는 Database를 Mocking을 한다고 할 때 진짜 메모리에 DB가 있는 경우를 말한다.
    실제 DB가 아니라 메모리 DB Fake와 같이 만들 수 있다.
  • Stub은 원하는 데이터를 바꿔서 내려줄 수 있는 기능을 하는 것을 말한다.
    ex) API 요청을 했을 때 네트워크에서는 ABC라는 데이터가 내려오는데,
    테스트하기 쉽게 하기위해서 네트워크에서 DEF라는 데이터를 내려주도록하는 것처럼 구현을 바꿔치기할 수 있는 것을 Stub이라고 한다.
  • Spy는 어떤 메서드를 호출하거나 변수에 접근했을 때 그 내용을 기록하는 것이다.
    말 그대로 Spy이다.
  • Mock은 Spy가 기록한 것과 Stub이 만들어 놓은 가짜 데이터를 이용하여 검증까지 하는 역할을 수행한다.

Mock과 Spy의 가장 큰 차이는
Mock은 Mock 데이터 그 자체가 테스트를 실패시킬 수 있다.
왜냐하면 Mock 데이터 안에 assert문이 있기 때문이다.

5)

TDD의 단점은 무엇인가요?

  1. TDD를 왜해야하는지 설득하기 어렵다.
  2. TDD에 익숙해지는데 시간이 걸린다.
    TDD는 유닛테스트를 잘 작성하고 숙련된 유닛테스트 작성 방법을 얻으면 2번의 단점을 해결할 수 있을 거라고 한다.

6)

TDD하기 쉬운 아키텍처는 좋은 아키텍처이다.

하지만 테스트만을 위해서 만든 아키텍처는 좋은 아키텍처가 아니다.

그런데 반대로 좋은 설계는 테스트하기 쉽다.
(즉, TDD하기 쉬운 아키텍처는 좋은 아키텍처라는 의미인듯 하다.)

7)

모든 뷰 컨트롤러에 유닛테스트를 하시나요?

전수열님은 모든 뷰컨트롤러에 유닛테스트를 하신다고 한다.

8)

현업에서 TDD를 적극적으로 활용하고 계신가요?

0개의 댓글