TDD 특강 | 이론, paradigm shift를 잘 활용하는 사람이 될 것

소프트웨어 = 문제를 푸는 도구

도메인 = 소프트웨어가 풀어야 할 문제가 정의되는 공간

(ex. 비즈니스 시스템의 도메인은 비즈니스)

 문제를 충분히 이해하지 못하면 문제를 푸는 도구를 잘 만들 수 없음

 

비용 효율

--> 시스템 구축 비용 + 시스템 운영 비용 < 인력 운용 비용 

환경에 따라 시스템 구축 비용은 크게 변화함 (항상 응용프로그램을 통한 문제해결이 실용적인 것은 아님)

 

테스트 코드란 ?

도메인 지식 흐름

 

요구사항

도메인 영역의 문제에 대한 시스템 영역의 해결책 (위 그림에서 오른쪽에서의 해결책)

현재까지는 컴퓨터는 스스로 설계를 결정하지 않기 때문에 코더가 도메인 지식을 컴퓨터에 전달할 때엔 모든 요소들이 명확히 결정될 수 밖에 없음 --> 코더는 충분히 명확한 도메인 지식을 확보해야 함. 그렇지 않은 코더는 지식 흐름 상류에 지식 보장을 요청해야 함 (도메인 전문가, 분석가 등에게)

but 어떤 코더는 스스로 결정을 내림 --> 도메인 지식 투영에 오차 발생, 무책임하고 위험 !

 

테스트 코드

가시적이고 구체적인 요구사항의 표현

자가검증 (요구사항이 실행되었는지 스스로 검증)

반복 실행 (수행하는 활동이 자동화되어서 저렴하게 반복 실행 가능)

클라이언트 (운영 코드를 사용하기 때문에 클라이언트 역할을 하게 됨)

 

TDD란 ?

테스트 코드 작성 (X)

 

절차

1. 다루려는 테스트 시나리오의 목록을 작성한다

어떤 요구사항을 만족시켜야 하는지를 적어보는 것 (구체적으로)

중요하지만 많이 간과하는 단계

 

2. 목록에서 정확히 하나의 항목을 실제적, 구체적이며 실행 가능한 테스트로 변환한다

 

3. 테스트(및 이전의 모든 테스트)를 통과하도록 코드를 변경한다 (항목을 발견할 때 목록에 항목 추가)

요구사항을 만족시키는게 가장 중요한 궁극적인 목적. 여기에만 집중해서 코딩

--> 성공하는지 확인하면서 디자인을 개선

--> 이를 하고 나서 4로 넘어가기

 

빼먹은 요구사항의 경우에는 테스트 목록에 새로 추가

 

4. 필요에 따라 구현 디자인을 개선하기 위해 리팩터한다

시간이 충분하지 않다면 생략 가능

5. 목록이 비워질 때까지 2로 돌아간다

 

--> 이 절차를 반복하는 것이 TDD

 

* 목적 중심

어떻게 구현할지가 아니라 목적 달성에 집중

도구를 충분히 연마해 목적 달성을 위해 사용할 때까지 가치 생산 상승

많은 프로그래머들이 목적보다 도구에 집중 또는 집착함

 

* 피드백

'지금까지 올바르게 진행되었나 ?'

굉장히 짧은 사이클로 피드백을 받을 수 있는 장점 (하나씩 수행하기 때문에)

피드백은 코더의 작업 환경에서 가까울수록 이로움

 

* 비용 관리

TDD 하는 것이 오히려 더 많은 비용을 발생시키는 경우 발생

 

숙련: 

테스트 코드 효과 - 테스트 코드 관리/실행 비용 > 수동 테스트 효과 - 수동 테스트 비용 --> 효율적

반복 연습이 필요함

 

AI (코파일럿 등)

테스트 코드 작성 비용이 절감됨

 

** 취업 시장의 분위기가 많이 변한 지금
AI의 등장 등의 paradigm shift가 급격하지만 이를 잘 활용하면 오히려 기회가 될 수도 !

 

---

https://github.com/ahastudio/til/blob/main/blog/2016/12-03-tdd-faq.md

til/blog/2016/12-03-tdd-faq.md at main · ahastudio/til

팀원 분이 공유해주신 자료 !