[Swift][TDD] 테스트 주도 개발! + (테스트를 해야 하는 이유)

- Test를 하는 이유 ( 해야하는 이유 )

1. 안전해진다.

"제품이든 앱이든 테스트를 거치는 이유는 제품의 안정성을 높이기 위해서" == "앱의 완성도를 높이기 위해서" 라 생각합니다.

 

2. 믿을 수 있기 위해.

단위테스트는 가장 작은 단위들부터 테스트를 하고, 범위를 점점 넓혀 이전에 테스트한 객체를 활용하여 상위객체를 테스트하는 방식을 반복합니다. 그러다 보면 객체 재활용시에도, "이 기능은 믿을 수 있는 기능이야!" 라는 확신이 생기게 되고, 오류가 발생하더라도 "이 행동들의 케이스에서는 오류가 나지 않았어"라는 확신을 갖을 수 있습니다.

 

해당글을 생각날 때 마다 읽으며 테스트 개념을 익히는 중입니다. ( 돌아서면 까먹어요 ㅜㅜ )

https://ssowonny.medium.com/%EC%84%A4%EB%A7%88-%EC%95%84%EC%A7%81%EB%8F%84-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%BD%94%EB%93%9C%EB%A5%BC-%EC%9E%91%EC%84%B1-%EC%95%88-%ED%95%98%EC%8B%9C%EB%82%98%EC%9A%94-b54ec61ef91a

 

 

- 무엇부터 테스트해야 할까?

1. 보이는 것 부터!

보이는 기능들은 모두 테스트할 수 있습니다! 모든 기능들을 테스트한다면, 앱 기능들에 대한 안정성이 높아지겠죠! 이는 앞서 말씀드린 테스트를 하는 이유 중 하나입니다.

다만 스위프트 기준 "UI가 잘 변경 되었는지"와 같이 UIKit의 작동여부와 같은 부분들은 UnitTest가 아닌 UITest에서 해야 할 것입니다.

 

2. 앱에서 가장 불안전하다 생각하는 부분들.

"모바일앱에서 가장 불안전한 부분은 뭐라 생각하냐?" 라고 물어본다면 아마 네트워크 통신하는 쪽 이 아닐까 싶습니다.

외부(서버)의 영향과 네트워크 상태 등 여러가지 불안전한 요소들이 많기 때문입니다.

저는 Mock객체를 생성하고, 테스트하는 상황이라 가정한 후, 성공 시 데이터가 잘 설정되는지, 실패 시 오류를 잘 반환하는 지 테스트합니다.

 

- 테스트 원칙? 그게 뭐에요?

First원칙입니다.

- Fast : 단위테스트는 빨라야한다.

- Isolated : 다른테스트에 종속적인 테스트는 절대 작성하지 않는다.

- Repeatable : 몇번을 실행하더라도 같은 결과가 나와야 한다.
- Self - vaildating : 테스트는 스스로 결과물의 옳고 그름을 판단할 수 있어야한다. ( 특정상태를 만들어야 동작하는 테스트는 작성하지 않는다.)

- Timely : 실제 서비스의 코드는 테스트가 성공하기 직전에 만들어져야 한다.

 

- 알았으니까 TDD가 뭔지 말해주세요

Test Driven Develop - 테스트 주도 개발입니다.

다른 개발방법으로 Behavior Driven Develop 가 있습니다.

TDD로 개발하는 이유!

1. 테스트를 완료한 후 기능을 작성하기에 안전성이 올라간다.

2. Refactor과정에서 실제 로직에도 적용시키기 위해, 의존성이 낮은 설계를 하고, 코드를 작성하게 됩니다.

 

- TDD Cycle

 

1. Red - 오류가 나는 코드를 작성한다. 실패하는 테스트 코드를 작성.

2. Green - 오류가 나는 코드 + 실패한 테스트코드를 최소한의 실행 및 통과가 되도록 수정한다.

3. Refactor - 해당 코드를 실제 테스트하는 코드로직으로 변경한다.

 

- TDD 예시

현재 만들고 있는 프로젝트로직의 일부분인 파이어베이스에서 데이터를 가져오는 로직입니다.

 

1. Red

존재하지 않는 객체타입과 이를 인스턴스 생성하려 한다니! 라며 빨간줄이 생기네요.

간단한 로직입니다. Firebase에서 PlaceDTO를 가져오는 작업입니다.

 

2. Green

해당 오류를 풀어주는 최소한의 코드를 작성해볼게요.

테스트에서 사용을 원했던 객체와 해당 메소드들을 구현해주었습니다.

오류가 풀리고 테스트가 성공했네요 :)

 

3. Refactor입니다.

실 객체에서는 stub과 같은 로직이 아닌 실제 Firebase를 사용하는 로직이 구현되야 하기에 해당 동작을 추상화하였습니다.

 

이제 나머지는 해당 추상화를 채택한 실객체를 구현할 예정입니다.

코드입니다.

https://gist.github.com/rising-jun/9bc98b550f4a0eb820f8794b36f9ccd9

엥? 이제보니 실객체가 테스트되는게 아니고 Stub객체를 테스트하는 코드 아니에요?

맞습니다. modelCount란 변수로 사용하였는데, 사실은 해당 객체를 사용하는 Repository를 테스트한 것이죠.

위에서 말씀드렸듯 서버와 통신하는 로직은 매우 불안정합니다. 

1. 그렇다면 서버상태에 따라 테스트의 여부가 달라질 수 있습니다. ( - Repeatable : 몇번을 실행하더라도 같은 결과가 나와야 한다. )

2. 만약 회원가입과 같은 경우에서는 계속 회원이 등록될 수 있습니다.

 

그렇기에 Stub객체 즉 모조품을 만들어 Repository를 테스트한 것입니다.

관련 지식은 "Stub객체를 사용하는 이유", "Stub객체로 테스트를 하는 이유"를 키워드로 검색하시면 알 수 있습니다.

 

먼저 꼽히는 TDD의 단점은 "시간이 오래걸린다."입니다.

안정성이 높은 코드를 작성하는데 후다닥 작성하는 건 어렵다고 생각합니다.

 

 

테스트를 공부하고, 이에 대한 지식들을 모아 저만의 주관으로 글을 작성해보았습니다.

 

감사합니다!