본문 바로가기

iOS/iOS

iOS) 유닛테스트(Unit Test) 맛보기 이론 (1/3)

 

 

 

안녕하세요 :) 소들입니다

진짜 너무 오랜만이죠.. 네..

어떻게 지냈냐구요 ..? 어떻게 지냈어요.. ^.^..;;ㅋㅋㅋㅋ

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

 

작년은 큰 프로젝트를 맡게 돼서 너무 바빴구...

너무 바빴구.. 너무 바빴구.. (??) ..

그래도 담백한 인사 이후 1년 안지나서 왔자나요~!~!!

조회수 100만 달은 기념으로 왔심다 🎉

 

네 이번에 공부할 내용은

테스트 코드 중 Unit Test에 관한 것입니당 :)

다 아는 개념이라구여?

제가 원래 좀 뒷북 잘 치잖아여 🪘

간단한 개념(이번 편) > Xcode에서 맛보기 > 테스트코드 짜기

이렇게 총 3편이 될 것 같은데 오늘은 간단한 개념으로 가볍게 봅시당

모든 포스팅은 편의 말투로 합니다~!

 

 

 

 

1. 테스트 코드가 왜 필요 한가요?

 

자, 만약 우리가 다음과 같이 

 

 

func add(a: Int, b: Int) -> Int {
    return a + b
}
 

 

 

위와 같이 매개변수 a와 b를 더해주는 함수를 짰다고 해보셈

물론 간단한 로직의 함수고 내용만 봐도 문제 없이 잘 짰짢아용

할 수 있겠지만,

 

add라는 함수는

매개변수 a + b를 더한 값이, 결과로 리턴 된다는 것이 검증이 "" 되어있는 함수이기 때문에

우리는 그저 이 add 함수가 잘 짜여져 있을 거라 전적으로 믿고 사용하는 것밖에 되지 않음

만약 개발자가 실수로

 

 

func add(a: Int, b: Int) -> Int {
    return a + b + 1
}
 

 

 

이렇게 엉뚱한 코드를 짰다면,

이 함수는 분명 개발자 의도와 다르게 잘못된 결과를 return 할 거잖음??

 

따라서 우리가 이렇게 어떤 함수, 메서드를 짤 때

내부 구현을 문제 없이 했는지

1 + 1을 했을 때 원하는 2라는 결과값을 리턴하는지

애가 헤까닥 해서 1 + 1을 3으로 잘못 리턴하진 않는지

이런 "검증"의 결과가 필요하단 것임

 

따라서 함수나 메서드(Unit)가

제대로된 놈인지를 확인하는 과정이 필요하고,

그것을 검증하는 것이 바로

Unit Test라는 것임

 

이제 왜 테스트 코드가 필요한지 알겠음?

내 실수 줄이려고 하는거임 하하하

다들 졸릴 때 메서드 이상하게 구현 해본 적 있잖아~~~

 

 

 

 

이러면 안 되는 거잖아

코드가 나한테 이러면 안 되는 거잖아!!!

 

정리하자면

유닛 테스트에서 유닛(Unit)이라는 것은,

함수메서드 정로도 생각하면 될 것이고

 

이 함수나 메서드가

문제 없이 의도대로 잘 동작 하는지,

원하는 결과 값을 리턴 하는지,

얼마나 빠르게 실행하는지

 

를 테스트 하는 것이 바로 유닛 테스트(Unit Test)

라고 보면 됨!!

 

 

 

 

2. Unit Tests / Integration Tests / UI Tests

 

사실 테스트 코드를 짠단 것에

유닛 테스트만 존재하는 것은 아님

 

 

 

위 그림처럼 테스트는 피라미드 형태를 띄고 있는데!!

가장 맨 밑단에 존재하는 영역이 바로 유닛 테스트임

 

"유닛 테스트"는,

위에서 함수나 메서드들이 

제대로 동작하는지, 얼마나 빠르게 동작하는지를

테스트하는거라 했잖음??

 

"통합 테스트"는

한단계 더 업그레이드 되어서,

두 가지 이상 기능들이 유기적으로 잘 동작하는지를 테스트 하는 것임

내 앱과 서버가 잘 통신하고 있는지, 데이터베이스에 정상적으로 연동은 되는지 등

다른 프로그램과의 연동을 테스트 함!

물론 유닛 하나하나를 봐야하는 유닛테스트보다 테스트 갯수는 적겠지만,

다른 기능과의 유기적 동작성을 보는 것이기 때문에, 테스트가 기능적으로 훨씬 더 복잡함!!

 

"UI 테스트"는

사용자의 입장에서 기능과 동작을 테스트 하는 것으로

로그아웃 버튼 눌렀는데 로그아웃이 제대로 되는지,

넌씨눈 회원가입 창이 뜨진 않는지 등

이런 UI적인 기능성을 테스트 하는 것임

이또한 피라미드 구조상 테스트 갯수는 통합 테스트보다 적을 테지만,

테스트를 작성하고 유지보수 하는 것에 시간이 갱장히 많이 들어감

(디자인 바뀌면 UI 테스트도 바뀌어야함 ..;ㅁ;)

+ 테스트 시간도 훨 많이 들음

 

 

쨌든 이런 식으로 테스트 코드를 짜는 것엔

위와 같이 피라미드 형태의 테스트들이 있다~ 정도만 알면 될 것 같음

 

 

 

 

3. 유닛 테스트의 5가지 규칙

 

깨끗하고 맑고 자신있는 🍀

유닛 테스트를 작성하기 위해서는

FIRST라는 5가지 규칙을 따르라고.. 하는데

 

F(ast) :

테스트는 빠르게 동작하여야 하며, 

자주 돌릴 수 있어야 한다

 

I(ndependent) :

각 테스트는 서로 의존하면 안 되며,

독립적이어야 한다

(너네 둘 떨어져 🙄)

 

R(Repeatable) :

테스트는 어떤 환경에서도 반복 가능해야 한다

테스트가 돌아가지 않는 환경이 있으면 안된다

(테스트 실패 변명거리만 됨 🙄)

 

S(Self-Validating) :
테스트가 성공 했는지, 실패 했는지는 Bool 값으로 결과를 내야 한다

(테스트 결과는 통과 아님 죽음뿐 🙄)

 

T(Timely) :

테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현해야 한다

(사실 제일 어렵다 🙄)

 

 

네 대충 별 거 없져??

사실 마지막이 젤 어려운듯 ㅋ

테스트 코드를 밀린 과제하듯이 마지막에 작성하면 안되는데 말이쟈..

이상과 현실의 괴리야

 

 

 

 

4. 유닛 테스트 코드를 작성해서 얻는 이점이 그래서 뭔데?

 

일반적으로 테스트 코드를 작성한다고 하면,

유닛 테스트를 의미하긴 함

따라서 유닛 테스트의 장단점을 봐보겠음

 

 

🌞 장점 

 

"코드의 안정성 향상"

- 반복되는 테스트를 통해 이 과정에서 버그를 빨리 찾아낼 수 있음!

 

"모듈성 증가"

- 코드(메서드, 함수) 등이 기능별로 독립적으로 분리됨!

 

"새로운 기능 추가 시 빠른 테스트 가능"

- 유닛 테스트는 해당 부분만 독립적으로 테스트 하기 때문에

시간을 많이 잡아먹는 통합 / UI 테스트와 달리 

새로 기능이 추가되거나 코드를 리팩토링 하여도

빠른 테스팅 및 문제 여부를 확인할 수 있음!

 

 

🌚 단점

 

기획자 : "빠르게 개발 안 돼요ㅠ?"

- 테스트 코드를 짠다는 것

테스트를 진행 한다는 것

그것은 곧 개발 시간이 증가한다는 것,,

 

"유지보수는 조상님이 해주시나"

- 기능이 바뀔 경우
테스트 코드 유지 보수에 대한 부담도 증가

 

"다른 객체와 미팅? 어림도 없어"

- 객체 자체가 독립적으로 모두 일을 처리하면 문제가 없지만,

다른 객체와 소통이 필요한 객체가 있을 수 있잖음?

근데 유닛 테스트는 독립적이어야 하기에 다른 객체와 메세지를 주고 받으면 안 됨 (테스트 코드 모솔이슈)

따라서 다른 객체 가면을 쓴 가짜 객체 (Mock Object)를 주입해서

어떤 결과를 반환해라! 하고 정해진 답변을 준비시켜야 하는데(Stub)

어쨌거나? 이것도 다 일이다

 

 

 

 

 

 

 

 

 

.

.

.

오늘은 테스트 코드의 간단한 이론에 대해 알아봤습니다

다음 포스팅에선 Xcode에서 테스트코드 어떻게 사용하는지에 대해 알아볼게용

조만간 봬요 ^^

 

 



Calendar
«   2025/04   »
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30
최근 댓글
Visits
Today
Yesterday