13. 국내
수시로 리팩토링을 통해 코드가 깔끔해진다
사이드 이펙트를 바로 알 수 있다
코드에 문제가 없다는 안도감
정해진 양만큼 개발
사양 변경이 용이
14. 국내
한번에 두개의 코드를 작성하기 쉽지 않아
개발기간 증대
개발하는 사람들의 교육 필요
리팩토링 목적 혼탁
테스트에 얽매이게 된다
15. 의견
• 약간 회의적
• SI에서는 절대 쓰기 힘든 방법론
• 자사서비스 애정을 갖고 시도하기엔 괜찮을지도
• 이념 자체는 훌륭하나.. 이상주의적인듯
• 진입장벽이 높다
• 테스트는 중요하니까 결과적으론 좋은 개발방법론
• 개발 마무리시 테스트코드를 정리해야 할 듯(너무 느려짐)
• 테스트를 통한 안정감은 꽤나 나에게 만족감을 줄 거 같다
• TDD를 완벽하게 재현하지 않는 경우도 있다(필요한 만큼)
• 리팩토링을 수시로 하게 되는 건 좋은 습관인 듯
실패할 수 밖에 없는 코드를 짜고 이를 해결하는 코드를 짜는 순환구조를 이용한 개발방법
크게 단위테스트와 인수테스트가 있는데 인수테스트는 사실상 사람의 영역이고 단위테스트가 주를 이룬다.
인수테스트도 작성할 수는 있지만 영역이 너무 크다는점?
이론적으로는 애자일 프로그래밍안의 익스트림 프로그래밍 방법론을 따른다.
자주반영, 사이클개발, 정해진 스펙, 테스트코드, 리팩토링 등 익스트림 프로그래밍의 기본원칙을 준수하라고 권한다
기본적으로 애자일 개발방법론의 하나이므로 solid 원칙을 따라간다
실패하는 테스트 코드를 작성
테스트 코드를 해결하는 코드를 작성
리팩토링
그림에는 명시가 안되어 있을뿐 사이사이 공정에는 테스트가 들어갑니다.
구체적으로 표현하면 이렇게
또 TDD의 기본 구성은
기획-설계-코드작성 순서지만
테스트코드 작성중 문제가 있는 부분은 기획으로 올려 다시 프로세스를 돈다
테스트 단위로 돌기 때문에 피드백이 빠르게 돈다는 장점
여기서 BDD(행동주도개발)을 추가하면
비개발자, 혹은 고객이 설계단에서 액터의 행동을 명시하는게 BDD다
이제 개발자는 설계 단계에서 액터의 행위를 보고 문제 여부를 파악한뒤 개발을 진행하는,
기획의 문제를 한단계 앞서서 파악할 수 있는 조합이다.
또한 액터의 행동을 기술하였으므로 이것을 기반으로 테스트 케이스를 작성할 수 있다.
BDD는 기획에 따른 액터의 행동을 명시하는데
3개의 단계가 있다.
Given : 액터의 상황, 액터의 조건을 기술
When : 액터의 행동, 시나리오를 기술
Then : 결과 노출
프론트에서 시나리오를 기술할때도 사용가능
해당 상황에서 에러인 상황은
로그인을 하지 않은 사용자의 경우를 기술하지 않았다는 것을 설계 단계에서 알 수 있으므로
기획에서 다시 검토를 요청할 수 있다.
테스트가 기록된다는 건 테스트 문서를 따로 생성할 필요가 없다고도 할수있고 개발도중 다른사람에게 공유가능하기 때문에 소통하기 쉽다.
명시되어있는 테스트로 기능을 구현하기 때문에 목적이 분명하여 구현하고자 하는게 분명하다
추가 구현이 용이하다는 것은 새로운 기능을 추가하는게 아니라 기개발된 코드에 어떤 기능을 추가할때 사이드이펙트를 체크하기 용이하다는 뜻이다.
기개발된 코드에 기능추가를 하고 테스트를 돌려보면 다른곳에서 잘못된 결과가 나오는지 확인하기 쉽다.
테스트를 작성하면서 설계 혹은 기획에 결함이나 이상을 미리 체크해두거나 재설계를 요청할수있다.
이는 시간이 급한 SI, SM 시장에서 개발기간이 늘어나는 현상을 방지할 수 있다.
루비 온 레일즈의 창시자 데이비드 하이네마이어 핸슨은 2014년에 TDD는 죽었다 라는 내용의 글을 작성하게 되고 TDD에 회의를 느낀 사람들의 지지를 많이 받았다.
그는 레일즈를 개발하면서 TDD를 사용하기도 하였고 처음 TDD를 접했을때 이 방법론이 많은 개발자들을 구하게 될것이라 생각했다고 전했다.
하지만 시간이 지나면서 HDD는 날이 갈수록 TDD에 회의감을 느끼게 되며 자신이 본 TDD 지지자들의 문제를 꼬집어 얘기하게되었다
테스트 케이스로 명시된 구현에만 치중하다보니 테스트 이외의 구조, 설계, 명확한 코드 등에 소홀히 하게된다.
하고싶은 테스트만 진행하고 복잡한 코드나 DB, file I/O를 테스트를 피하는 경향이 많다.
클린코드를 지향하자고 하는것은 TDD를 하는 사람들이 클린코드보다 코드 커버리지 같은 부분은 우선시하는 경향을 비판한것입니다.
캔트백이 말하는 rio tdd는 죽었다는 뜻이 아니라 보낸다면 보냄으로써 tdd에 받았던 것들을 나열해주고있습니다.
Tdd가 자신에게 해주는 구현 명시, 스펙 명시, 피드백, 오류캐치, 테스트 문서, 설계-개발 프로세스 피드백, 협업 소통, 초록불 등을 그리워하게 될 것이라 알리고 있습니다.
실제로 TDD로 개발하는 방식은 이러한 이점을 주고있었고 캔트백은 이러한 이점을 가진 새로운 개발론을 찾아야 하게 될 것이라는 답안을 해주었습니다.
런던학파는 테스트 코드와 프로덕트를 종속적으로 연결하여 더욱 깊은 테스트가 이루어지도록 합니다.
리턴값보다는 메서드가 호출 되었는지, 호출에 대한 올바른 정보를 전달하였는지에 중점을 둡니다.
이러한 검증을 상호작용기반검증이라고 하며 mock framework로 확인합니다.
런던학파 TDD는 일반적인 TDD보다 좀더 작고 세밀하게 디자인하여 각 테스트 요소별 작은 단위까지 테스트하기때문에 타 TDD보다 비용이 증가하는 경향이 있습니다.
TDD의 방식에는 리팩토링 작업이 껴있다.
테스트할때마다 리팩토링을 진행하기 때문에 나중에 하게될 리팩토링 작업을 개발중 수시로 진행할 수 있다.
전체적으로 단위테스트를 실행하며 자신이 수정한 코드가 사이드 이펙트를 발생시켜 문제가 일어나는지 알수 있다.
테스트 자동화를 통한 안도감
TDD의 개발 이념에 따른 정해진 양만큼의 개발
일반적으로 숙련된 사람이 아닌 이상 복수의 코드를 한번에 작성하기 어렵다.
이는 개발기간 증가라는 최대의 단점과 연결되는데 국내에서는 SI가 활발하고 무엇보다 납기가 중요하므로
국내 많은 개발자가 채택하기 어렵다고 꼽는다.
TDD는 개발할 때 전부가 채택했다고 해도 인원이 끝까지 유지되는지는 별개다.
중간에 인원이 바뀌거나 충당 될때마다 해당 개발에 대한 교육이 필요하다.
수시로 진행하는 리팩토링 과정에는 코드 커버리지를 위해 불필요한 코드가 추가되거나
테스트를 통과하기 위한 임의적 코드를 남겨버리는 경우가 있다고 한다. 우리는 이것보다 명확한 코드 작성에 힘을 써야하지 않을까
결국 TDD도 넓게 보면 더 나은, 더 간결한, 더 이상적인 개발을 위해 도입하지만,
테스트에 너무 깊이 들어간 나머지 완성해야할 코드보다 테스트코드에 더 집착하게 되는 주객전도가 일어난다.
