TDD(Test-Driven Development)

🚀 TDD란 무엇인가

Test-Driven Development(TDD)는 매우 짧은 개발 사이클의 반복에 의존하는 소프트웨어 개발 프로세스이다.

TDD는 설계 이후 코드 개발 및 테스트 케이스를 작성하는 기존의 개발 프로세스와 달리,

테스트 케이스를 먼저 작성한 후 이 테스트가 통과할 수 있는 실제 코드를 개발하여 리펙토링 하는 절차를 따른다.

이러한 이유로 TDD를 Test First Development라고도 한다.

 

 

♻️ TDD 사이클

xenonstack

1️⃣ Add a test
2️⃣ Run all tests and see if the new test fails
(처음에는 production code가 없기 때문에 테스트가 실패하는게 당연)
3️⃣ Write the code
4️⃣ Run tests
5️⃣ Refactor code
6️⃣ Repeat

 

 

🤷‍♀️ Why TDD?

TDD를 왜 사용해야 할까?

1. 내가 어떤 코드를 작성해야 하는지가 명확해진다.

테스트를 통과하기 위한 코드를 작성해야 하기 때문에 작성해야 할 코드의 목표가 분명해지고,

테스트 시나리오를 작성하면서 다양한 예외사항에 대해 생각해볼 수 있다.

이는 개발 진행 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있다.

 

2. Test Coverage를 거의 100%로 만들 수 있다.

Test Coverage란 전체 코드의 몇 퍼센트가 테스트 되었는지를 나타내는데 TDD 프로세스를 적용하면 거의 모든 코드가 적어도 한 번씩은 테스트되기 때문에 test coverage를 거의 100%로 만들 수 있다.

여기서 거의라는 말이 붙는 이유는, 현실적으로 모든 코드에 테스트를 수행할 수 없으며 테스트를 수행한다고 해서 버그가 발생하지 않는 것도 아니기 때문이다.

 

3. 사전에 다양한 케이스를 고려해봄으로써 잠재적 오류들을 미리 해결할 수 있다.

 

4. 추가 구현이 용이하다.

개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 알지 못한다는 것이다.

하지만 TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있다.

이러한 TDD의 장점을 보장받기 위해서는 반드시 지켜야할 TDD의 3가지 원칙이 있다.

 

 

🚦 TDD의 3가지 원칙

1. 실패한 단위 테스트를 작성할 때까지 production code 작성하지 말 것

2. 테스트 코드를 한번에 너무 많이 짜지 말 것

3. 테스트가 통과될 정도의 production code만 작성할 것

 

 

🤦‍♀️ TDD 단점

1. 생산성의 저하

TDD 방법론을 적용하게 되면 처음부터 2개의 코드(test code, production code)를 짜야하고, 중간중간 테스트를 하면서 고쳐나가야 하기 때문이다.

따라서 TDD 방식의 개발 시간은 일반적인 개발 방식에 비해 좀 더 늘어나게 된다.

 

2. 높은 진입장벽

TDD를 처음 접하는 사람들에게는 그냥 코드를 작성하는 것도 쉽지 않은데 아직 작성되지 않은 코드에 대한 테스트 코드를 어떻게 쓰냐는 의문이 들 수 있다.

따라서 TDD에 익숙하지 않은 사람들은 적응 시간이 꽤 오래 걸린다.

 

 

🔗 References

JaeYeopHan/Interview_Question_for_Beginner

tddtest-driven-development