건강한개발자블로그

테스트 주도 개발 (TDD)는  더 나은 소프트웨어를 만들기 위한 기법 중 하나다.

테스트 코드를 작성해야 하는이유?

1. 코드의 정상작동 유/무를 확인하기 위해서, 소프트웨어에 대한 피드백 과정이 줄어든다.

( 소프트웨어 출시에 있어 피드백 과정이 줄어드는 것이 프로젝트 전체의 일정으로 보았을때 매우 효율적이다 )

2. 새로운 하부시스템을 전체 프로젝트에 통합하기 전에도 매우 유리하다. 

3. 운영되는 코드에 대해 문제를 빨리 알수 있고 수정이쉽고 비용이 낮아진다.

테스트 코드 작성시 알아아두어야 할것.

1. 최대한 많은 개발자 테스트를 자동화 하는것이 핵심.

2. 테스트 코드 작성에 따라 코드 작성시간이 올라갈 수 있지만 코드의 품질을 생각하여 테스트를 수행하는것이 좋다.

3. 잘못된 테스트 코드는 불필요한 리소스를 낭비할 수 있지만 테스트 코드 작성자가 테스트 코드에 대해 이해하고 적절한 테스트 전략을 세운다면 테스트 코드는 작성하지 않을 이유가 없다.

4. 모든 단계의 소프트웨어 스택과 개발 프로세스에 대해 테스트를 수행해야 한다. 특히 가장 작은 범위에서 테스트를 수행해야 피드백 과정 ( 문제발견 / 수정 )을 줄일 수 있다. 

테스트의 유형

- 유닛 테스트

가장 작은 단위의 기능에 대한 테스트를 단독으로 수행하는 것. 각각의 함수가 정확히 작동하는지 확인하기 위한 것.

- 통합 테스트

통합 테스트를 통해 각각의 단위 모듈을 더 큰 결합체로 통합하여 작동시키는 복합 기능을 검증할 수 있다.

- 시스템 테스트

'end-to-end tests' 이 테스트를 통해 전체 시스템에 대한 요구사항 명세를 확인할 수 있음. 통합된 소프트웨어 스택 전체에 수행되는 테스트로서, 프로젝트에 대한 검수 기준으로 사용됨.

테스트 작성 시기

1. 코드를 작성할때 ( 테스트코드를 같이 작성, 나중에 할 수록 테스트 효과가 줄어듬 )

2. 출시코드에 대해 버그를 수정할 때 ( 코드수정을 바로 하지말고 버그의 원인을 설명하는 실패 유닛 테스트를 작성하라 )

3. 빌드과정에서 테스트를 끼워넣을 수 있도록 하자.

테스트 대상

요구사항에 맞게 테스트하라 ( 어떠한것도 테스트대상이 될 수 있다 )

좋은테스트

1. 짧고 명확한 이름을 가지고 있어 실패했을때 원인파악이 쉬움.

2. 유지보수가 쉬움.

3. 수행에 오랜 시간이 걸리 지않음.

4. 최신 구현 코드(작업물)에 맞춰져 있음.

5. 특별히 머신 설정이 필요 없다.

6. 다른 테스트에 대한 의존성이 없어서 특정 테스트 전후에 실행할 필요가 없다. 외부 상태나 코드상의 어떤 공유 변수에 대한 의존성이 없다.

7. 실제 구현코드를 테스트 한다. ( 복제본이 아님, 복제본은 쓸모없을 수 있음 )

나쁜테스트

1. 일정한 결과값을 갖지 않음 ( 때로는 성공, 때로는 실패 )

2. 유지보수하기 힘든 테스트

3. 지나치게 큰 테스트

4. 하나의 테스트케이스에서 둘 이상을 수행하는 테스트

5. 직접 작성하지 않은 서드파티 코드에 대한 테스트

6. 필요하지 않은 기능에 테스트하는 테스트

7. 기능이 보장되어있는것까지 하는 테스트 ( ex: 속성의 getter, setter에 대한 테스트 )

8. 단 하나의 머신에서만 수행 가능한 테스트

테스트의 형태

- 테스트의 기본 프로세스

배치( 검사를 실행할 준비 ) - 실행 - 검증 ( 예측된 값이 맞는지 검사 실행 )

- 테스트 이름

명확한 테스트 명명을 하는것이 좋음.

테스트의 구조

- 테스트가 코드의 중요 기능을 모두 다른 점을 보장하라.

- 테스트는 중복해서 수행하지 않는다. ( 중복 수행은 노력과 혼란, 유지 보수 비용을 가중시킴 )

- 코드의 특정 행태를 확인하는 테스트를 작성하라.

테스트 유지 보수

- 테스트코드는 깔끔하게 다듬고 리팩토링을 하라.

- 코드를 수정하고 테스트케이스를 제거하지마라 테스트케이스 또한 유지보수를 하라.

출처: 훌륭한 프로그래머 되는 법

7장. 똥통에서 뒹굴기

나쁜 코드를 언제든 만날 수 있다는 마음의 준비를 하라. 나쁜 코드를 다룰 때 쓸 강력한 도구들을 미리 준비하라

고약한 코드중 몇몇은 그저 실력이 부족한 프로그래머가 짰을 뿐이다. ( 절대로 본인이 선호하는 스타일이 아니라고 새로 작성하지 말라 )

코드의 품질을 측정할 수 있는 질문들

- 외부에 노출하는 API는 깔끔하고 합리적인가?

- 자료형을 잘 고르고, 변수 명을 적절히 지었는가?

- 코드의 레이아웃을 정돈하여 일관성 있게 작성했는가?

- 객체들의 협업 구조가 보기에 간결하고 명확한가? 아니면 코드베이스 전반에 제어 구조가 예측할 수 없게 얽혀 있는가?

- 특정 기능을 구현하는 코드 부분이 어디에 있는지 쉽게 찾을 수 있는가?

어떤 작업을 할지 선택에 집중하라 ( 시간을 낭비하지 말라 )

보이스카우트 규칙을 따르라. 어떤 코드를 건드리든 이전보다 나아지도록 하라.

4장. 코드 줄여 개선하기

1. 의미가 있을 때만 코드를 작성하라.

2. 당장 필요하지 않다면 지금 작성하지 말라

불필요한 코드에 대한 대가

- 유지보수되어야 한다. ( 물론 시간과 돈이 든다 )

- 여분의 코드는 프로젝트를 파악하기 어렵게 만드는만큼, 추가적인 이해와 검토가 필요하다.

- 백만 개의 메서드를 가진 클래스는 주의 깊게 프로그래밍할 수 없으며 엉성하게 작성할 수 밖에 없다.

- 리팩토링, 최적화는 더 어려워진다.

불필요한 코드를 없애는 방법

- 작업할때 주의를 기울여라

- 작업후에는 확실하게 정리하라

- 정기적인 코드리뷰를 실행하라

미래에 필요할지도 모르는 기능이라도 코드를 제거하라 ( 버전관리 시스템에서 되돌릴 수 있다 )

질문 

1. 프로그램에서 작동하지 않는 '죽은 코드를' 어떻게 식별할 수 있는가?

- 에디터, 메서드호출등을 통해 알 수 있다. ( 그외에도 개발자가 식별: 유지보수, 코드리뷰 )

2. 현재 일시적으로 필요하지 않은 코드를 제거할때, 형상관리툴에 주석처리하여 눈에 띄게 남겨두는가?

- 눈의띄게 남겨두는 편인데 그냥 삭제하는것이 헷갈리지 않고 코드 레이아웃을 해치지 않고 좋은것 같다

3. 사용하지 않는 레거시 기능을 제거하는 것은 항상 적절한가?

- 정말 간혹가다 다시 참조해서쓰거나 하는 경우가 있는데 거의 필요없어서 동작방식만 이해하고 삭제하는것이 옳다고 본다

4. 현재 프로젝트의 코드베이스에서 불필요한 부분이 얼마나 되는가?

- 그래도 많지 않다고 본다 5%미만이라고 생각한다.

5장. 코드베이스의 망령

프로그래머로서의 자질은 자신이 작성한 코드가 아닌, 그것을 대하는 태도와 작성하는 방식에 의해 결정된다.

오래된 코드를 다시 살펴보는 것은 코딩 기술 등을 향상시키는데 도움을 준다.

설계기술이 느는 방법 : 경험, 실수, 여러 코드를 읽어보고, 재능 있는 다른 개발자와도 일해보아라

질문 

1. 예전의 코드가 지금은 어떻게 보이는가? 그다지 나빠 보이지 않는다면, 최근에 새로운 뭔가를 배우지 않았음을 뜻하는 것인가?

- 상황에 따라서 다를수 있을거 같다.

2. 주요 언어로 얼마나 오랫동한 일했는가? 그사이 언어 표준이나 내장 라이브러리가 얼마나 많이 바뀌었는가? 당신의 코드를 작성하는 스타일을 형성할때 어떤 언어 기능에 영향을 받았는가?

- c#, mssql 고정된버젼형식을 사용하여 최신의 표준을 따라가지는 않았다 javascript의 경우 새롭게 es6가 나와서 그 형식대로 작성한 경우가 있었다

3. 무의식적으로 사용하는 일반적인 관례의 일부에 대해 생각해보자. 이들이 오류가 발생하지 않도록 하는 데 무엇이 도움이 되는가?

- 암묵적으로 믿고간다고 생각하는데 사실 다른것들과의 상호작용을 깊게 생각하지 않기때문에 잠재적오류를 범하고 있는 것 같다

6장. 경로 탐색하기

이미 존재하는 프로젝트에서 적응하기위해 해야할 것

1. 코드의 어느 부분부터 보아야 하는지 파악하기

2. 코드의 부분별 기능을 알아내고, 그 그닝을 어떻게 수행하는지 살펴보기

3. 코드의 품질을 가늠하기

4. 시스템 내부를 어떻게 탐색할 것인지 계획하기

5. 코딩 관례를 이해하고, 본인의 수정 사항이 그것과 어울리도록 만들기

6. 특정 기능이 있을 법한 위치를 파악하고, 그 기능에 의해 발생하는 버그 찾아보기

7. 코드와 함께 그것의 중요한 부속 부분들인 테스트 코드 및 문서등의 관계를 이해하기

도움을 요청할때의 자세

1. 언제나 공손하고 감사하라.

2. 합리적이고 적절한 질문을 하라.

3. 질문하기에 앞서 구글링 하라

4. 혼자 알아낼 수 있는 질문은 하지말아라

1장. 코드에 신경 쓰기

평범한 프로그래머와 훌륭한 프로그래머의 차이 : '태도'

좋은코드를 작성하는 방법

1. 의도가 드러나는 코드 ( 남이 쉽게 파악하고 이해할 수 있어야 함)

2. 유지보수가 가능해야 함 ( 자신이나 다른 프로그래머들이 쉽게 파악하고 이해할 수 있어야 함)

3. 정확해야 함 ( 문제를 풀었다는것을 증명할 수 있어야 함, 정삭작동을 확인해야 함 )

질문

1. 코드에 신경 쓰는가? 자신이 만든 결과물에서  그 점이 어떻게 드러나는가?

- 상대방이 잘이해할 수 있도록 최대한 쉽게 작성한다. 드러나는지는 확인하지 못하여 방법을 찾아야한다.

2. 프로그래머로서 더 나아지고 싶은가? 가장 노력해야 하는 부분은 어떤 부분인가?

- 성능에 대한 공부를 조금 더 해야할거 같다 + 다른 개발자들과의 협업도 생각해야 할 거 같다.

3. 코드에 신경 쓰지 않는다면, 왜 이책을 읽고 있는가?

- 코드에 신경을 쓰고 있다. 그외에도 앞으로 개발을 위해 알아두면 좋은 부분을 공부하고싶어서 책을 읽고 있다.

4. 좋은 프로그래머가 나쁜 코들르 만들 수도 있는가? 어떻게 그럴 수 있는가?

- 좋은 프로그래머 일지라도 코딩에 대한 공부를 하지 않으면 좋지 않을 수도 있다.

2장. 정돈된 코드 유지하기

관객을 위해 코딩을 하라

나의 코드를 읽는 사람 : 나, 다른동료, 미래의 유지보수 프로그래머

레이아웃 : 전체 형태와 구조를 파악할 수 있도록 작성해야 한다.

일관성 : 한가지를 골라서 일관성 있게 사용하자 ( 기본 라이브러리의 스타일을 따르는것을 추천 ) 

3장. 코드 적게 쓰기

코드는 명백하고 간결하게 작성하라

코드에 신경 써야 하는 이유

1. 코드를 길게 많이 쓸수록 유지 보수 비용은 높아진다.

2. 코드가 많을수록 읽고 이해해야 할 내용이 많음을 의미한다.

3. 코드가 많을수록 버그가 숨을 수 있는 공간도 많아진다.

4. 중복코드는 치명적이다.

∙리팩토링 : 코드가독성을 높이고, 내부구조를 향상하며, 유지 보수를 원할히 하기 위한 것이다

( 프로그램의 작동 방식을 바꾸는 '개선' 이다. UI의 조정 또한 '정돈'이지 리팩토링이 아님을 뜻한다 )

모든 주석이 코드에 가치를 더하지는 않는다는 것을 명심하자. 코드만으로는 이유가 명확하게 드러나지 않았을 때만 주석을 달아야 한다.

적절한 공백은 코드 구조에 도움이 된다. 적절학 괄호 역시 로직을 명확하게 만들어 준다.