Software Testing

1. Unit Test

• 유닛테스트란 내가 작성한 코드의 가장 작은 단위인 함수를 테스트하는 메소드입니다.
• 유닛테스트는 빠르고 비용이 싸므로 개발할 때 필수적으로 작성해야 합니다.

2. Testing Pyramid

• Google Test Automation Conference에서 제안된 테스트 피라미드
• 시스템을 테스트할 때 3가지 방법으로 나눌 수 있습니다.
• 전체 테스트 비중을 아래와 같은 수치로 구현하는 것이 권장된다.
  • E2E(UI) Testing -> 10%
  • Integrating Testing -> 20%
  • Unit Testings -> 70%

2-1. End-To-End Testing/ UI Testing

• 크롬브라우저를 띄운 다음에 내가 만든 검색페이지로 들어가서 검색을 해보고 검색한 내용이 제대로 나오는지 화면상에서 확인하거나 직접 회원가입을 해보고 회원가입후에 로그인 되는지 직접 브라우저 상에서 값을 입력해서 테스트하는 방법
• UI Testing이 가장 어렵고 까다롭습니다.
• Manual Testing은 실행하기 쉽다는 장점이 있지만 비용이 많이 들고 부정확하며 실행 시간이 오래 걸립니다.
• 자동화할 수 있지만 UI Testing은 자동화하기가 가장 까다롭고 또 실행하기도 까다롭습니다.

2-2. Integration Testing

• 최소 두 개 이상의 클래스 또는 서브 시스템의 결합을 테스트하는 방법
• 예를 들면 장고로 서버를 띄우고 모델 클래스와 결합하여 데이터베이스 시스템과 연동한 테스트
• Postman 또는 httpie로 호출해서 Json response가 제대로 출력되는지 확인
• Integration Testing이 E2E Testing 다음으로 공수가 많이 듭니다.

2-3. Unit Testing

• Unit Testing이 가장 쉬우며 효과가 좋습니다.

3. Unit Test 장점

• 유닛 테스트는 UI Test 또는 Integration Test보다 테스트 비용이 싸다.
  -> UI Test는 백엔드 서버와 프론트를 연동하여 사람이 직접 테스트하지만, 유닛 테스트는 사람이 스크립트로 한꺼번에 자동으로 실행하기 때문입니다.

• 유닛테스트는 다른 테스트에 비해서 실행 속도가 매우 빠릅니다.
  -> 유닛테스트를 활용하면 하루에도 배포를 여러번 할 수 있어 개발 및 배포 속도에 중요한 영향을 주기 때문에 개발할 때 최대한 활용하는게 좋습니다.

• 새로운 기능을 구현할 때 유닛 테스트를 잘 작성해놓으면 중장기적으로 유지 보수가 쉬운 장점이 있습니다.
  -> 즉, 이전에 통과했던 테스트 집합을 가지고 버그를 찾기 위해서 이전에 테스트되었던 유닛테스트를 반복하는 것을 regression 테스트라고 하는데 유닛테스트만 반복하면 되기 때문에 regression 테스트도 반복적으로 수행할 수 있습니다.

• 유닛테스트를 잘 짜놓으면 유닛테스트가 되었던 코드에서는 버그가 거의 발견되지 않고 대부분 버그가 발견되는 경우는 유닛테스트가 없어서 발생하는 경우가 많습니다.
  -> 만약 사후에 발견된 버그에 대해서도 버그를 수정한 후 유닛테스트를 작성해놓으면 버그를 방지할 수 있습니다.

4. Test의 일반 원칙

• 테스트 유닛은 각 기능의 가장 작은 단위에 집중하여, 해당 기능이 정확히 동작하는지를 증명해야 합니다.

• 각 테스트 유닛은 반드시 독립적이어야 합니다.
  -> 각 테스트는 혼자서도 실행 가능해야하고, 테스트 슈트로도 실행 가능해야 합니다.
  -> 이때, 호출되는 순서와 무관하게 잘 동작해야 합니다.
  -> 새로운 데이터셋으로 각각의 테스트를 로딩해야하고, 그 실행 결과는 꼭 삭제해야합니다.
  -> 보통 setUp()과 tearDown() 메소드로 이런 작업을 수행합니다.

• 테스트가 빠르게 돌 수 있도록 만들기 위해 노력해야 합니다.
  -> 테스트에 필요한 데이터 구조가 너무 복잡하고, 테스트를 하려면 매번 이 복잡한 데이터를 불러와야 해서 테스트를 빠르게 만들 수 없는 경우도 있습니다.
  -> 이럴 때는 무거운 테스트는 따로 분리하여 별도의 테스트 슈트를 만들어 두고 스케쥴 작업을 걸어두면 됩니다.
  -> 그 외의 다른 모든 테스트는 필요한 만큼 자주 수행하면 됩니다.

• 지금 사용하고 있는 툴이 개별 테스트나 테스트 케이스를 어떻게 수행하는지 배우셔야 합니다.
  -> 모듈 안에 들어있는 함수를 개발하고 있다면, 그 함수의 테스트를 자주, 가능하다면 코드를 저장할 때마다 자동으로 돌려야 합니다.

• 그 날의 코딩을 시작하기 전에 항상 풀 테스트 슈트를 돌려야 합니다.
  -> 끝난 후에도 마찬가지입니다. 이 작업은 내가 다른 코드를 망가뜨리지 않았음을 확인할 수 있습니다.

• 모두가 공유하는 저장소에다가 코드를 집어넣기 전에 자동으로 모든 테스트를 수행하도록 하는 훅을 구현하는 것이 좋습니다.

• 지금 한창 개발 중인데 그만두고 잠시 다른 일을 해야한다면, 다음에 개발할 부분에다가 일부러 고장난 유닛 테스트를 작성하는 것도 좋습니다.

• 코드를 디버깅할 때 가장 먼저 시작할 일은 버그를 찝어내는 새로운 테스트를 작성하는 것입니다.
  -> 이런 일이 언제나 가능한 것은 아니지만, 이런 버그잡이 테스트들이야말로 당신의 프로젝트에서 가장 가치있는 코드 조각이 될 것입니다.

• 테스트 함수에는 길고 서술적인 이름을 사용하셔야 합니다.
  -> 테스트에서의 스타일 안내서는 짧은 이름을 선호하는 다른 일반적인 코드와는 조금 다릅니다.
  -> 테스트 함수는 절대 직접 호출되지 않기 때문입니다.
  -> test_square_of_number_20 같은 함수명들은 테스트가 실패할 때만 보이니 반드시 가능한 한 서술적인 이름을 붙여야 합니다.

• 무언가 잘못되었거나 뜯어고쳐야만 할 경우, 괜찮은 코드에 테스트 셋이 있다면 당신이나 다른 유지보수 담당자들은 오류를 수정하거나 프로그램의 동작을 수정할 때 필시 그 테스트 슈트에 전적으로 의지할 것입니다.

• 테스트 코드의 또 다른 사용 방법은 새로은 개발자들을 위한 안내서로 쓰는 방법입니다.
  -> 이미 만들어져 있는 코드에서 작업해야할 경우, 관련 테스트 코드를 돌려보고 읽어보는 것이야말로 가장 좋은 시작점일 경우가 많습니다.
  -> 이렇게 테스트 코드를 돌려보면 어느 지점이 문제인지, 수정하기 어려운 곳은 어디일지, 막다른 골목은 어디일지를 발견하게 됩니다.
  -> 몇 가지 기능을 추가해야 한다면 가장 먼저 해야할 일은, 그 새로운 기능이 아직 돌아가지 않음을 확인할 수 있는 테스트를 붙여넣는 것입니다.