본문 바로가기

TDD, TestCode

테스트코드 그거 좋다는데 언제 해야되나요?

개인적 경험

최근 구인공고를 보면, 테스트코드 관련해서 우대사항에 집어넣는 회사들이 대다수더라.

(사실상 필수)

 

그래서 그런지 내가 수료한 내일배움캠프에서도 과정에 포함되어 있었다. 다만 좀 내용이 어렵기때문에 나를 비롯한 다른 팀원들도 약간 당황하기는 했다.

 

Mocking이니, 의존성이니 하는 용어가 갑자기 튀어나오니...

확실히 Nest.js는 편하다. 알아서 테스트(Jest)에 맞춰서 폴더구조같은것도 다 짜주니까

그냥 Run만 누르면 되는 수준이다. 그래서 처음에는 너무 편하고 신기했는데...


그렇다고 Nest가 없는 상황에서 '저는 네스트에서 해주는대로만 해봤는데요'라고 하면 좀 

당황스러울것 같아서 조금씩 이제 테스트코드(TDD)에도 내 발판을 놓아보려고 한다.

 

 가장 기본적인 테스트 피라미드이다.

 

아래부터 

Unit - 함수나 모듈 단위 테스트

Integration - 통합된 기능에 대한 테스트(전체적)

E2E - 엔드 투 엔드(실상황) 에 가까운 테스트

 

정도로 간편하게 나눌수 있따.

 

아래에서 위로 올라갈수록 

오래 걸리고, 어려운건 어쩌면 당연한 이치.

 

사실 테스트코드도 새로 구성해야되는것도 시간과 노력이 들어가는데,

모든 기능에 대해 테스트를 하기는 힘들고, 필수와 필수가 아닌 부분을 나누는게 좋다.

 

기본적으로

 

1. 중요한 비즈니스 로직

2. 프로그램의 요구사항이 명확함

3. 협업시

4. 문서화시

 

물론 테스트코드를 짰다고 해서, 버그가 안난다는 보장은 없다.

다만 최소한의 안전장치로서의 가치가 있기 때문에 하는 것이다.

'TDD, TestCode' 카테고리의 다른 글

Mock 과 Stub 의 차이는?  (0) 2023.05.24
단위테스트 AAA 패턴, FIRST, Right - BICEP, CORRECT  (0) 2023.05.22