[패스트캠퍼스 수강 후기] 자바 인강 100% 환급 챌린지 22회차 미션

오늘은 스프링 부트 프로젝트 5강부터 들어보았다.

 

 

 

---

5강. Test Driven Development

 

이 프로젝트는 TDD의 방법으로 진행될 것이라고 한다.

---

TDD란?

테스트 주도 개발(Test-driven development TDD)은 매우 짧은 개발 사이클을 반복하는소프트웨어 개발 프로세스중 하나이다. 개발자는 먼저 요구사항을 검증하는 자동화된 테스트 케이스를 작성한다. 그런 후에, 그 테스트 케이스를 통과하기 위한 최소한의 코드를 생성한다. 마지막으로 작성한 코드를 표준에 맞도록리팩토링한다. 이 기법을 개발했거나 '재발견' 한 것으로 인정되는Kent Beck은 2003년에 TDD가 단순한 설계를 장려하고 자신감을 불어넣어준다고 말하였다.

출처: 위키백과

 

Red, Green, Refactoring

의 사이클에 따라 테스트를 하면서 구현해나가는 방법이다.

 

<추가공부>

출처:https://blog.naver.com/junhwen/221492130432

 

1. 정의

- TDD는 반복 테스트을 이용한 소프트웨어 개발법이다. 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 소프트웨어를 구현한다.

* 참고 URL

- TDD(The Bad Parts):https://www.youtube.com/watch?v=xPL84vvLwXA

- 테스트 피라미드:https://martinfowler.com/articles/practical-test-pyramid.html

- 테스트 자동화와 TDD:https://www.slideshare.net/hoonsbara/tdd-41738171

 

​

2. 장단점

​

2.1 장점

1)클린 코드를 위한 확신.버그율이 낮은 코드 작성을 위해서는 "클린 코드"를 작성해야한다.

하지만 처음부터 제대로된 클린 코드 작성에는 무리가 있음. 이에 통상 선 구현후

리팩토링을 통해 이를 개선해나가는것이 일반적임. 그러나 시스템이 복잡할수록

리팩토링에 부담이 생긴다, 왜냐하만 만약 어떤 부분을 수정하였을경우, "시스템의 사이드이펙트에 대해

파악 및 감당"이 되지 않기 때문이다. 이에 리팩토링을 진행할 경우 "강한 확신이 있어야 가능"하다.

이를 도와 주는것이 테스트 케이스 이다. 잘 정의된 테스트 케이스가 존재하는 경우

코드수정 이후에도 즉각적인 테스트가 가능하기 때문에 개발자는 리팩토링 에 확신을 가질 수 있다.

2) 높은 소스 코드 품질

- MS 와 IBM 사의 조사 결과 TDD 약 15~35% 의 개발시간 증가 하였지만, 결함율(버그)는 40~90% 줄어듬.

3) 재설계 시간의 절감

4) 손쉬운 테스트 근거 산출 및 문서화

5) 디버깅 시간의 절감

2.2 단점

1) 생산성 저하

2) 러닝 커브

3) 납기일 준수 우선순위가, 코드 품질 우선순위보다 높은 경우, 적용에 어려움

 

*TDD는 어떤 조직에서든 상당한 부담을 갖는 챌린지인것이 사실이다. 많은 개발자들 및 조직에서 도입시도 후, 실패하는 사례가 빈번한 방법이다.

짧게는 몇개월 내에 시도 후 포기하는 경우도 많은데, 이에 따라 최소 1년이상의 장기적인 관점을 가지고

1) 익숙해지는 연습 2) 프로젝트별 다양한 사례에 대한 다양햔 정책 테스트 3) 이를 지속 진행하여 발전시키는 꾸준함 이 필요하다.

 

​

3. 실행 절차

- 이미지 도식

 

​

4. TDD 규칙 및 정의

 

1) TDD 3 가지 그라운드 룰

(1) 실패하는 테스트를 작성하기 전에는 절대로 제품 코드를 작성하지 않는다.

(2) 실패하는 테스트 코드를 한 번에 하나 이상 작성하지 않는다.

(3) 현재 실패하고 있는 테스트를 통과하기에 충분한 정도를 넘어서는 제품 코드를 작성하지 않는다.

​

2) TDD 와 Test Case 는 다르다.

- TDD 는 하나의 개발 방식으로, Test Case 를 작성하는 것과 의미상으로는 다른 분류에 속한다.

​

* TDD 방식으로 반드시 개발해야 하는가?

- TDD 방식을 현업에 맞게 조금씩 수정하여 적용해야 한다고 본다. 또한 Test Case 는 반드시 필요하다는 고 생각한다.

- 조금더 정확하게 말하면 상기의 그라운드 룰 3을 반드시 지키는것에 집중하기 보다는,본인의 프로젝트에 반드시 필요한

테스트 케이스에 대해 집중해보는 자세가 중요하다.

​

5. 룰에 따른 절차 예시

1) Test Case : sum(1,2) 는 3을 출력해야한다.

// CalculatorTest.java publicvoidsumTest() { assertEqual(Calculator.sum(1,2),3); }

 

2) Production: sum 함수를 작성함.

// Calculator.java publicvoidsum(intleft,intright) { return3; }

 

3) Test case : sum(2,3) 는 4를 출력해야한다.

// CalculatorTest.java publicvoidsumTest() { assertEqual(Calculator.sum(1,2),3); assertEqual(Calculator.sum(2,2),4); }

​

4) Production: sum 함수를 리팩토링함.

​

// Calculator.java publicvoidsum(intleft,intright) { returnleft+right; }

* 최종 완성시에는 -> 프로덕션 코드가 생성되어있고, 이에 대한 다양한 테스트 케이스가 이미 작성되어있음.

 

4. 테스트 분류

 

​

5. 통합 테스트 vs 유닛 테스트

​

- 예를 통하여 통합 테스트 케이스와 유닛 테스트 케이스 영역을 살펴 보려함.

​

1) 질문: 편의점 카운터에서 물건을 스캔한 뒤에 고객에게 최종 가격을 알려주는 프로그램이 필요합니다.

물건들의 가격은 데이터 베이스에 있으며, 한가지 특별한 것은 현재 모든 물건을 2개 사면 하나 더 주는 이벤트를

하고 있기 때문에 이 로직을 반영해야함.

​

2) 테스트 예시

 

6. 위험성 & BDD

- 다양한 프로젝트의 TDD 적용 실패 사례를 분석한 결과, 몇가지 공통적인 문제가 존재하였으며, 이를 해결하기 위한

방안으로 제시 되는것이BDD 를 적용한 TDD이다.

6.1 위험성

1) UI 테스트 관계 역전

- UI 테스트는 제일 최소화 버전으로 진행해야한다.(integrationTest, unitTest 중심)

2) Unit test

- 테스트 커플링 => 클래스 1 : 테스트 1 = X

3) 커버리지율에 대한 위험성

- 100% 지향은 프로젝트 전반에 치명적인 문제를 줄수 있다.

 

6.2 BDD

- BDD 를 적용한 TDD 는, 테스트 케이스의 대상 선정이 단순이 클래스 단위가 아니라, 비지니스 로직에 의해 결정된다는 것이다.

예를 들어 A라는 유저가 로그인할때 패스워드가 틀린경우 등의 시나리오를 먼저 나열하고 이에 따른 테스트 케이스를 적용하는것이다.

해당 경우, 특정 컴포넌트 및 클래스에 종속적인 형태에서 벗어날수 있게 된다.

​

* 테스트를 위한 테스트를 작성하는것은 프로젝트의 큰 비용 낭비이다. 이에 위험성을 긴밀히 고려하여 정책을 설정하여야 한다.

* 성공적인 TDD 를 위해서는 BDD 를 적용하여 진행해야한다.

​

7. Integration Test 작성 사례

 

- 링크 추가 예정

​

8. 결론

- TDD 의 필요성 및 진행 방식을 확인하였고, 위험성 또한 알아보았다. 제일 빠지기 쉬운 문제인

모든것을 테스트한다는 개념은, 프로젝트 자체를 망치는 경우가 빈번하다. 효과적인 적용을 위해서는 BDD 의 관점으로 접근 해야한다.

이에 따라 장기적인 관점을 가지고 프로젝트별 제일 효과 적인 방법을 찾기 위해 지속적인 개발이 필요할것이다.

 

 

---

 

그 후 강의를 따라 듣는데 여러가지 문제가 발생했다...

 

오늘 오랜만에 이걸 고치려고 또 시간을 엄청 잡아먹으면서 갑자기 인강의 한계를 깨달았다.ㅋㅋㅋ

 

하지만 다행히 이 강의를 듣는 사람들이 이미 많은 시행착오를 하고 해결책을 블로그에 써두어서 참고할 수 있었다.

 

내가 참고한 글 중에 글제목이 '빡쳐서 쓰는 공부글' 이 있었는데ㅋㅋㅋㅋㅋㅋ 너무 많은 공감이 되었다.

 

이분이 쓴 오류글을 미리 다 읽어봤는데, 벌써 오류로 헤매고 있을 내가 보인다...ㅋㅋㅋㅋㅋㅋ

 

 

강의 버전과 현재 다운받을 수 있는 버전이 다르고, 바뀐 것들이 반영이 안되어서 여러가지 조치를 해줘야 하는 것 같은데

 

강의는 초보자 강의라면서 홈페이지에는 이런것들을 어떻게 대처해야 하는지에 대한 정보가 하나도 안나와있다...

 

 

유튜브 강의만 해도 밑에 댓글란에 다른 사람들이 써놓은 것을 보면서 고치기라도 할 수 있는데, 

 

여기는 댓글란도 없고... 이런건 너무 불편한 것 같다.

 

어쨋든 일단 내가 할 수 있는데까지 최대한 해보면서 고친 것들은 블로그에 남겨보도록 하겠다.

 

 

오늘 고친건

 

우선 어제 auto import를 하지 않았어서 아래 글을 보고 auto import 조치를 했다

 

http://blog.daum.net/debianizer/16995529

 

 

또 import가 안되는 것들이 있어서 아래 글을 보고 조치했다.

 

https://blog.naver.com/2mcinme/222060746090

 

 

 

---

 

---

6강. Rest API

 

Rest API 란?

출처 : 위키백과

REST(Representational State Transfer)는월드 와이드 웹과 같은 분산하이퍼미디어시스템을 위한소프트웨어 아키텍처의 한 형식이다. 이 용어는 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개되었다. 필딩은HTTP의 주요 저자 중 한 사람이다. 이 개념은 네트워킹 문화에 널리 퍼졌다.

엄격한 의미로REST는 네트워크 아키텍처 원리의 모음이다. 여기서 '네트워크 아키텍처 원리'란 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다. 간단한 의미로는, 웹 상의 자료를HTTP위에서SOAP이나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다. 이 두 가지의 의미는 겹치는 부분과 충돌되는 부분이 있다. 필딩의REST아키텍처 형식을 따르면HTTP나WWW이 아닌 아주 커다란 소프트웨어 시스템을 설계하는 것도 가능하다. 또한,리모트 프로시저 콜대신에 간단한XML과HTTP인터페이스를 이용해 설계하는 것도 가능하다.

필딩의REST원리를 따르는 시스템은 종종 RESTful이란 용어로 지칭된다. 열정적인 REST 옹호자들은 스스로를 RESTafrians 이라고 부른다.

 

---

CRUD 란?

Create

Read

Update

Delete

 

출처: 위키백과 

 

CRUD는 대부분의컴퓨터소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말이다. 사용자 인터페이스가 갖추어야 할 기능(정보의 참조/검색/갱신)을 가리키는 용어로서도 사용된다.

CRUD 대신에 다음과 같은 유사용어가 사용되기도 한다.

• ABCD: add(추가), browse(보기), change(변경), delete(삭제)
• ACID: add(추가), change(변경), inquire(질의), delete(삭제)[1]
• BREAD: browse(보기), read(읽기), edit(편집), add(추가), delete(삭제)
• VADE(R): view(참조), add(추가), delete(삭제), edit(편집), 트랜잭션 처리에서는 restore(복원) 추가

각 문자는 다음과 같이 표준 SQL문으로 대응 가능하다.

이름조작SQL

Create	생성	INSERT
Read(또는 Retrieve)	읽기(또는 인출)	SELECT
Update	갱신	UPDATE
Delete(또는 Destroy)	삭제(또는 파괴)	DELETE

CRUD 용어를 최초로 사용한 논문으로는 Kilov, H(1990)의 논문이며, 그 개념은 Kilov(1998)에도 자세히 서술되어 있다.

유저 인터페이스 CRUD는, 여러응용 프로그램의 사용자 인터페이스에도 들어맞는다. 예를 들어, 주소록나 전화번호부 소프트웨어를 생각해볼 수 있다. 여기서 기본적인 기록 단위는 각 개인의 연락처이다. 다음과 같은 기능들은 가장 간단한 것이면서도 필수적이다.

• 새로운 연락처 정보를 추가할 수 있다.
• 기존의 연락처 정보를 검색할 수 있다.
• 기존의 연락처 정보를 편집할 수 있다.
• 기존의 연락처 정보를 삭제할 수 있다.

이러한 4개의 조작을 모두 할 수 없다면 그소프트웨어는 완전하다고 할 수 없다. 이들 기능은 매우 기본적이기 때문에, 한 묶음으로 설명되는 경우가 많다.

 

---

URI / URL​

사실 URI, URL이 의미상으로 크게 차이가 있는 것은 아닙니다.

때문에 얼마 전까지만 해도 저는 둘을 구분하지 않고 그냥 혼용해서 사용을 했었습니다.

하지만 프로그래밍을 공부하는 사람이라면 정확한 차이를 알고 쓰는 게 맞는 것 같습니다.

​

우선 URI와 URL의 이니셜을 풀어보면 다음과 같습니다.

URI = Uniform Resource Identifier = 통합 자원 식별자

URL = Uniform Resource Locator = 통합 자원 위치

​

URI와 URL 모두 인터넷상에 존재하는 어떠한 자원(웹 문서, 이미지, pdf파일등)의 위치를 나타내는 주소입니다.

둘은 비슷하지만 URI가 좀 더 큰 개념. 즉, URI는 URL을 포함하는 개념입니다.

다음 그림을 보겠습니다.

두 주소는 모두 index.html파일을 가리키고 있습니다.

① 은 웹서버의 실제 파일의 위치를 나타내는 주소 즉, URL이면서 URI입니다.

② 의 경우 웹서버에 실제로 index라는 파일은 존재하지 않기 때문에 URL은 아닙니다. 하지만 rewrite를 통해 index.html파일을 가리키고 있기 때문에 URI라고 볼 수 있습니다.

​

요즘은 rewrite를 통해 실제 웹 페이지의 파일 이름을 숨기는 경우가 많습니다.

다음은 네이버 블로그 홈 주소입니다.

BlogHome.nhn이라는 파일은 실제로 네이버 서버에 없을 겁니다. 때문에 위 주소는 URI로 칭해야 합니다.

최근에는 이렇게 실제 파일 위치가 아닌 특정 문자열로 자원의 주소를 표현하는 경우가 많기 때문에, URI와 URL의 차이를 알고 구분해서 사용하도록 노력합시다!

 

출처: https://blog.naver.com/rnjsrldnd123/221501904861

 

---

 

---

 

패스트 캠퍼스 강의 : https://bit.ly/3ilMbIO

Java 웹 개발 마스터 올인원 패키지 Online. | 패스트캠퍼스