• 신뢰성
• 지속가능성
• 성능
• 가독성

TDD

TDD workflow

sprint를 기준으로 설명!

1. 코드를 짜기 전에, 명세서를 적는다.
   • 함수 interface, 클래스 명세 등등
2. 이를 위한 Test Code를 작성한다.
3. 테스트를 수행한다. 통과하지 못하면 Production code 를 다시짠다.
4. 다 통과했다면 refactoring한다.

sprint2

1. sprint2에서 만들 기능을 정의하고 테스트 코드를 작성한다.
2. Production 1의 정돈된 코드를 기반으로 해당 테스트 코드가 돌아가는지 확인한다.
   • 만약 한개라도 true가 나온다면, 테스트코드를 잘못짠 것이다.
   • production 2의 코드가 생산되지 않았는데 어떻게 통과?
3. 모두 fail이 뜬다면 다음단계로 넘어간다.
4. production 2코드를 작성한다.
5. 테스트를 돌린다.
6. 코드를 정돈한다.

• 굉장히 짧은 개발 과정을 반복하는 것!
• 테스트 케이스를 바탕으로 확인하면서 가는 과정
• 소프트웨어가 버전업되는 것을 경험하면서 갈 수 있음
• Agile은 얼마안됐지만, TDD는 사실 오래됐다.
• Kent Beck이 “재발견”했다.
• Agile하고 TDD가 잘 맞아떨어짐
• 기존에 있는 코드가 현재 요구사항을 만족하는지 확인할 때도 사용
  • 안되면 안된 케이스에 대해 역량을 집중하는 것

TDD Cycle

• 1
  • 테스트를 새롭게 작성한다.
  • 매우 명확하고 심플하며 우리가 테스트하고 싶은 곳에만 집중해야 함
    • 올바르게 동작했을 때, 잘못되었을 때 등
  • 스펙, 요구사항에 대해 명확하게 이해한 사람이 할 수 있음
  • 그래서 시퀀스 다이어그램 이런 것들이 중요한 것
  • Use case에 대해 분석할 수 있어야 함
  • 테스트 코드를 잘 짜는 사람이 더 실력이 좋음
  • 두번째 부터는 수정된 테스트가 되는 경우가 많음
• 2
  • 테스트를 돌려보고 통과하지 않는지 본다.
  • 코드가 돌아가면 잘못된 것. 구현도 안했는데.
  • Fail이 나야 한다.
• 3
  • 코드를 짠다.
  • 목표는? : 테스트를 패스하기 위한 코드를 작성한다.
  • 이게 제일 중요. 우아하고 이딴거 필요없고. 요구사항만 만족해라
  • 무조건 통과만 해라. 이 이상의 것을 하지마.
  • +가 -가 될 가능성이 더 많을 수 있음
• 4
  • 테스트를 돌린다.
  • 이전에 만든 테스트까지 함께 돌린다.
  • 새롭게 만든 테스트가 잘돌아가면 개발자는 기분좋아도된다.
  • 근데 만약에 이전의 테스트가 안돌아간다?, 성능이 낮다?
    • 지금 만든 코드에 의해 이전 코드가 훼손된 것.
    • 문제를 찾거나, 안되면? Rollback..
• 5
  • Refactor code
  • 임시용 코드를 마스터에 집어넣는 과정
  • Merge할 때, 코드를 예쁘게하는 방법
  • 중복 제거
  • 이런 것이 코드 리뷰
  • 지속가능성과 신뢰성 향상, 즉 유지보수
  • 이름 예쁘게 지어라.
  • 상속 관계, 클래스 관계도 잘해야 함.
  • 이런 걸 잘하는 사람이 경력이 많은 사람, 가이드라인을 잘 따라야 함
  • 편집증 처럼 테스트를 주기적으로 계속해주는게 좋음, 조금씩 해서 테스트하는 방법 - 알고리즘짤때 처럼
• 반복..!
  • 새로운 테스트, 새로운 코드가
  • 너무 많은 양으로 하면 안되고, 적은, 적당한 양
  • 여차하면 revert가 가능해야 한다.
  • 남의 코드를 가져왔는데, 미심쩍으면 테스트 코드를 짜서 확인을 한다.
  • A부서, B부서 나름의 TDD로 짠다.
  • A에서 짠걸 B에서 테스트하겠다. -> A입장에서 놓치는 경향이 있을 수 있으니 하는게 맞다. 감정 상하지 말자.
    • 남을 우째 믿냐.
    • 남이 짠건 버그가 있다. 즉 철저하게 테스트를 하고 사용하는게 맞다. 믿지마.
    • 본인이 짠 것 이상으로 테스트..

변형 형태

변형 형태

인포그래픽!

개발자스럽게 이해해보자.

• Keep the unit small
  • 함수는 하나의 동작을 하도록 만들어야 하고, 명확하게.
  • 함수가 명확할 수록 하기쉬움
  • 그래야 디버그 노력이 줄어든다.
  • 너무 코드가 잘짜여져 있으면 (작게, 명확하게) doc이 덜필요함
    • 잘못 이해해서 일단 돌아가면 doc없어도 된다. 이게 아니고
    • 잘 짜여진 코드가 있으면 없어도 된다가 맞는것

Unit Test

Unit test

• Test case
  • Single test에 대해서 내가 원하는 하나의 케이스
• Test Suite
  • 그 test case의 집합
• Test Runner
  • 실제 이 테스트 케이스를 넣고 돌리는 녀석

Unit Test mock

mock 이해

• mockup : 모형을 한번 만들어 보는 것임
• mock object는 가짜 object!
• 실제 돌아가려면 필요한 객체가 있는데 이를 가짜를 사용해서 모사함으로써 프로그램의 동작을 확인하는 행위
• 위에서 초록색을 테스트하려면 상하좌우 퍼즐이 필요한데, 이를 오른쪽과 같이 생각하여 동작을 확인함

Profiling

• 프로그램을 분석함
• 프로그램의 메모리, 디스크, cpu 등의 분석
• 시간복잡도, 시간, 어디서 시간이 오래쓰이는지
• 사용하는 함수는 뭔지
• 함수의 call횟수는 얼마인지
• 이렇게 해서 최적화를 하는 것.
• 이런 것을 하도록 하는것이 profiler
• 파이썬은 이미 있다… profile

Coding Guideline (Convention!)

• 가독성의 핵심이다.
• 아주 중요한 편
• 소프트웨어의 유지보수
• 가이드라인 체킹 프로그램도 있다. 하라는 걸 해.