일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 맥린이
- mybatis
- controller
- jsp
- handlerMapping
- tiles
- Agile
- Cloud
- Framework
- system developer
- setAttribute
- MVC
- HTTP
- 프롬프트
- DevOps
- 내장객체
- usecasediagram
- getParameter
- ERD
- FrontController
- UML
- NOTE
- pattern
- App
- Program
- command
- getAttribute
- classdiagram
- Spring
- backend
- Today
- Total
시작은 언제라도
TDD (Test Driven Development) 본문
TDD란 매우 짧은 개발 사이클에 반복에 의존하는 소프트웨어 개발 프로세스이다.
좋은 코드를 위해 요구되는 새로운 기능에 대한 테스트 케이스를 작성 하고 그 테스트를 통과하는 가장 간단한 코드를 성한다.
테스트를 통과하는 코드를 작성하고 상황에 맞게 리펙토링하는 과정을 거치며, 테스트가 코드작성을 주도하는 개발 방식을 TDD라고 한다.
Add a test
새로운 기능 추가 전 테스트를 먼저 작성한다. 테스트 작성을 위해선 개발자는 해당 기능에 대한
요구사항과 명세를 분명히 이해하고 있어야한다. ---> 사용자 케이스와 사용자 스토리로 이해 가능하며 개발자의 코드작성 전에 요구사항에 집중할 수 있도록 도와준다.
새로운 기능 추가시 기존 기능이 작동하지 않을 경우가 발생할 가능성이 존재, 이를 개발자가 모르는 경우가 위험할 수 있음.
새로 추가할 기능을 미리 테스트 해봄으로서 새로운 기능이 작동함과 동시에 기존 기능들도 잘 되는지를 확인 할 수 있다.
코드량이 방대해진 후 refactoring 또한 테스트 코드가 잡아준다. 뚱뚱한 함수를 여러개로 나누는 과정에서 해당 기능의 오작동을 방지하기 위해 간단히 테스트 해봄으로서 안심을 하고 리펙토링을 진행할 수 있다.
보다 객체 지향적이고, 확장 가능이 용이한 코드, 재설계의 시간을 단축시킬 수 있는 코드, 디버깅 시간이 단축되는 코드가 TDD와 함깨 탄생하게 된다.
코드 작성에 대한 테스트는 어짜피 한번 해봐야한다. 그 부분을 자동으로 해주면서 코드 작성에 도움을 주는 것이 TDD이다.
하지만 TDD 라는 개발방식을 적용하기에는 진입장벽이 존재하고 여러 테스트 프레임워크 중 어떤 것이 우리의 서비스와 맞는지 등 여러 부분들에 대한 학습이 필요하고 익숙해지는데에도 시간이 걸린다. 또한 팀원 전체가 익숙해져야 빛을 바란다.
모든 코드에 대해서 테스트 코드를 작성할 수 없으며 작성할 필요도 없다. 또한 테스트 코드를 작성한다고 해서 버그가 발생하지 않는 것도 아니다. 애초에 TDD 는 100% coverage 와 100% 무결성을 주장하지 않았다.
'Common Sense > 개발 상식' 카테고리의 다른 글
업무 관련 (0) | 2021.10.11 |
---|---|
애자일 방법론 (0) | 2021.07.18 |
모듈 vs 컴포넌트 (0) | 2021.07.08 |
분석설계, 개발 환경, 적용기술 설명 (0) | 2021.06.29 |