14주차 [ETC] TDD란

ETC/CI, CD란.md

@@ -0,0 +1,62 @@
+# CI/CD란
+
+## 요약
+
+> 애플리케이션의 개발 단계를 자동화하여 짧은 주기로 고객에게 애플리케이션을 제공하는 방법
+
+## CI/CD가 나온 배경
+
+- 모든 개발이 끝난 이후에 코드 품질을 관리하는 고전적 방식의 단점을 해소하기위해 나타난 개념
+- 분업과 협업의 과정에서 코드의 Merge 과정은 까다롭고, 테스트하는데 큰 자원을 소비되게 된다. 이 문제를 해결하기 위해 도입
+- 개발 브랜치가 일정 기간 이상 이용되면, 통합의 어려움은 커지고 충돌 해결에 들어가는 시간이 길어지고 오류 발생 위험이 커진다.<br/>이러한 단점을 극복하고자 변동 내용의 반영 빈도를 늘리는 **자동화**가 등장
+
+## CI의 정의
+
+- **지속적인 통합(Continuous Integration)**
+- 어플리케이션의 **새로운 코드 변경 사항**이 정기적으로 **빌드 및 자동 테스트** 되어 공유 레포지토리에 **통합(병합)**하는 것
+- 개발자를 위한 자동화 프로세스(여러명의 개발자간의 코드 충돌을 방지하기 위한 목적)
+- 자동화된 테스트에서 **동작을 확인**하고 변경으로 인해 문제가 생기는 부분이 발견되면 CI를 통해 빠르게 수정 가능
+- 버그를 신속히 찾아 해결하고 소프트웨어 품질 개선, 새로운 업데이트의 검증 및 릴리즈 시간 단축시키는 것이 핵심 목표
+
+### CI를 만드는 데 필요한 4가지 규칙
+
+- 모든 소스 코드가 있고 누구나 현재 소스(및 이전 버전)를 얻을 수 있는 단일 장소 유지할 것
+- 누구나 단일 명령을 사용하여 소스에서 시스템을 빌드할 수 있도록 빌드 프로세스를 자동화 할 것
+
+- 단일 명령으로 언제든지 시스템에서 우수한 테스트 모음을 실행할 수 있도록 테스트 자동화할 것
+- 누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것
+
+> 이 중 가장 중요한 것이 **테스팅 자동화**!!<br/>지속적인 통합을 하기 위해서는 무엇보다 이 프로젝트가 완전한 상태임을 보장하기 위해 테스트 코드가 구현되어 있어야만 한다.
+
+## CD의 정의
+
+- **지속적인 서비스제공(Continuous Delivery)** or **지속적인 배포(Continuous Deployment)**
+  - **지속적인 서비스제공(Continuous Delivery)**
+    - 공유 레포지토리로 자동으로 Release 하는 것
+    - 운영팀이 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포 가능 (**수동적 배포**)
+    - 프로덕션 환경으로 배포할 준비가 되어 있는 **코드베이스를 확보**하는 것이 목표
+  - **지속적인 배포(Continuous Deployment)**
+    - 프로덱션 레벨까지 자동으로 deploy 하는 것
+    - 애플리케이션을 프로덕션으로 릴리스하는 작업을 **자동화**
+    - 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 애플리케이션을 **자동으로 실행**할 수 있는 것을 의미
+- 간단히 말하면 **배포 자동화 과정**
+- 서버가 많을 경우 개발자가 일일이 배포를 진행하지 않아도 되므로, 리소스가 낭비되지 않는다.
+
+![CI/CD flow](https://www.redhat.com/cms/managed-files/styles/wysiwyg_full_width/s3/ci-cd-flow-desktop_edited_0.png?itok=TzgJwj6p)
+
+## CI/CD 종류
+
+- Jenkins
+- CircleCI
+- TravisCI
+- Github Actions
+
+등..
+
+## 참고
+
+- https://www.youtube.com/watch?v=0Emq5FypiMM&t=10s
+
+- https://www.redhat.com/ko/topics/devops/what-is-ci-cd
+- https://devuna.tistory.com/56
+- https://www.martinfowler.com/articles/originalContinuousIntegration.html

ETC/TDD 방법론.md

@@ -0,0 +1,96 @@
+# TDD 방법론
+
+## TDD란?
+
+- **테스트 주도 개발**(Test Driven Development : TDD)은 반복 테스트를 이용한 소프트웨어 방법론 중 하나
+- 선 개발 후 테스트 방식이 아닌 **선 테스트 후 개발 방식의 프로그래밍 방법**
+- 다시 말해 자동화된 **작은 단위**의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 **반복**하여 구현한다. (ex. **JUnit**)
+- **짧은 개발 주기의 반복**에 의존하는 개발 프로세스이며, 애자일 방법론 중 하나인 eXtream Programming(XP)의 ‘Test-First’ 개념에 기반을 둔 단순한 설계를 중요시한다.
+
+> ❓ eXtream Programming(XP) 이란?
+>
+> - 미래에 대한 예측을 최대한 하지 않고, 지속적으로 프로토타입을 완성하는 애자일 방법론 중 하나
+> - 추가 요구사항이 생기더라도, 실시간 반영 가능
+
+## TDD 개발 프로세스
+
+TDD의 개발 방식을 알기 전 일반 개발 방식에 대해 알아보자
+
+### 일반 개발 방식
+
+```
+요구사항 분석 -→ 설계 및 디자인 -→ 코드개발 -→ 테스트 -→ 배포
+					↑______________________|
+```
+
+이러한 방식은 소프트웨어 개발을 느리게 하는 잠재적 위험이 존재한다.
+
+- 소비자의 요구사항이 처음부터 명확하지 않을 수 있다. 따라서 처음부터 완벽한 설계는 어렵다.
+  - 당연히 어느 프로젝트든 초기 설계가 완벽하다고 말할 수 없다. 재설계를 통해 점진적으로 완벽한 설계로 나아간다.
+  - 그러나 이 방식의 경우 재설계로 인해 삽입, 수정, 삭제 하는 과정에서 불필요한 코드가 남거나 중복처리 될 가능성이 크다.
+- 자체 버그 검출 능력 저하 또는 소스코드의 품질이 저하될 수 있다.
+  - 작은 부분의 기능 수정에도 모든 부분을 테스트해야 한다. (**전체적인 버그 검출이 어려워짐**)
+  - 어디서 버그가 발생할지 모르기 때문에 잘못된 코드도 고치지 않으려 하는 현상이 나타난다.
+- 자체 테스트 비용이 증가할 수 있다.
+
+📌 **즉, 결론적으로 재사용이 어렵고 관리가 어려워져 유지보수가 어렵다.**
+
+### TDD 개발 방식
+
+```
+								┌---리팩토링----┐
+								↓             |
+요구사항 분석 -→ 설계 및 디자인 -→ 테스트 코드 -→ 코드개발 -→ 배포
+					↑______________|
+```
+
+아래 그림은 개발 주기를 나타낸 것이다.
+
+- RED : 실패하는 테스트 코드 작성
+  - 실패 이유는 테스트 코드의 문제가 아닌 **운영 코드가 아직 변경되지 않았기 때문**이어야 한다.
+- GREAN : 테스트 코드를 통과하기 위한 실제 코드 작성
+- REFACTOR : 리팩토링 수행 (불필요한 코드 제거, 일반화 등)
+
+![TDD-개발주기](https://i0.wp.com/hanamon.kr/wp-content/uploads/2021/04/TDD-%E1%84%80%E1%85%A2%E1%84%87%E1%85%A1%E1%86%AF%E1%84%8C%E1%85%AE%E1%84%80%E1%85%B5.png?fit=1024%2C680&ssl=1)
+
+**📌 POINT!!**
+
+- 실패하는 테스트 코드를 작성할 때까지 실제 코드 작성하지 않아야 한다
+- 실패하는 테스트를 통과할 정도의 **최소 실제 코드**를 작성해야 한다
+- 이를 통해, 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있다.
+
+## TDD 장점
+
+1. 객체 지향적 코드 개발 가능
+   - TDD는 코드의 재사용을 보장해서 TDD를 통한 소프트웨어 개발 시 기능별 모듈화가 이루어짐
+   - 이는 의존성과 종속성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 함
+   - 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향 X
+2. 설계 수정시간의 단축
+   - 테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야하는지 분명히 정의하고 개발 시작
+3. 유지보수의 용이성
+   - 단위 테스트 기반의 테스트 코드를 작성하므로 추후 문제가 발생했을 때 각각의 모듈별로 테스트 진행 가능
+4. 테스트 문서의 대체 가능
+   - 일반 개발 방식에서의 테스트 정의서는 단순 통합 테스트 문서에 지나지 않는다.
+   - 하지만 TDD를 하게 된다면 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있다.
+
+## TDD 단점
+
+1. 사전준비 기간
+   - 사전에 필요한 지식을 습득하고 개발 환경 구축해야 함
+   - 효과적으로 사용할 수준이 되는데 보통 1 ~ 6개월의 시간이 필요
+2. 생산성 저하
+   - 2개의 코드를 작성해야 하고, 중간중간 테스트를 하면서 고쳐나가야 하기 때문에 일반 개발 방식에 비해 **개발 시간이 10~30% 증가**
+   - SI 프로젝트와 같이 품질보다 납기일 준수가 훨씬 중요한 경우 TDD를 잘 사용하지 않는다.
+
+> ❓ 실제로 TDD가 많이 쓰일까?
+>
+> - TDD 사용에 대해서는 아직도 많은 논쟁이 있다. 특히 많이 고민하는 문제가 바로 **생산성 저하**
+>
+> - TDD는 비용적인 측면에서 고민해야 한다. 테스트 코드를 짜는 것 또한 엄연한 개발이기 때문에 시간 투자 대비 이익이 있어야 한다. 너무 과도하게 테스트에 몰입해버린다면 시간 낭비나 다름없다.
+> - 즉, 적당한 TDD는 개발에 있어 능률 상승을 가져오지만 과도한 테스트는 오히려 해롭다.
+
+## Ref
+
+- https://wooaoe.tistory.com/33
+- [http://www.incodom.kr/테스트-주도-개발](http://www.incodom.kr/%ED%85%8C%EC%8A%A4%ED%8A%B8_%EC%A3%BC%EB%8F%84_%EA%B0%9C%EB%B0%9C)
+- [TDD는 항상 옳지 않다(비용의 문제)](https://architecture101.blog/2014/04/25/tdd-isnot-always-true/)