TIL/웹의 이해

Software Testing

시럽이 2022. 8. 6. 14:07

🚀 학습 목표

  1. 테스트 자동화의 중요성을 이해하고 설명할 수 있다.
  2. 시스템을 테스트하는 3가지 방법(UI test, Integration Test, Unit Test)을 설명할 수 있다.
  3. 유닛테스트의 중요성을 이해하고 설명할 수 있다.
  4. 유닛테스트의 장점을 설명할 수 있다.
  5. Unit test를 구현할때 지켜야 하는 일반적인 원칙들을 설명할 수 있다.

 

Unit Test

1. Unit Test란?

  • 유닛 테스트란, 내가 작성한 코드의 가장 작은 단위인 함수를 테스트하는 메소드 입니다. 그래서 내가 작성한 로직 을 테스트하는 유닛테스트 코드를 짜서 테스트하게 됩니다.
  • 지금까지는 주로 프론트는 크롬브라우저를 띄워서 실제로 동작시켜보는 E2E 테스트를 해왔을 것이고 백엔드는 장고 서버를 동작시키고 Httpie 나 포스트맨으로 주로 Integration 테스트를 수행하였을 것입니다.
  • 프론트의 경우 버튼을 추가해서 이벤트를 처리하는 신규 로직을 구현할 때마다 크롬 브라우저를 띄워서 테스트하고 이전 기능 또한 테스트 해야 하기 때문에 시간이 많이 소요될 수 있습니다.
  • 백엔드의 경우 테스트할 엔드포인트가 10개라면 이것을 httpie 나 포스트맨으로 테스트하면 최소 수분은 걸릴 것이고 엔드포인트 10개를 테스트하는 유닛테스트를 돌린다면 수초만에 테스트가 끝날 것입니다. 또한, Integration 테스트는 데이터베이스 서버를 돌려야 하고 메모리가 유닛테스트보다 더 많이 사용하게 되므로 비용도 비쌉니다.
  • 이처럼 유닛 테스트는 빠르고 비용이 싸므로 개발할 때 필수적으로 작성해야 합니다. 그럼 이제 유닛테스트에 대한 예제를 작성해보면서 자세하게 알아볼까요 ?

 

2. Testing Pyramid

  • Google Test Automation Conference에서 제안된 테스트 피라미드
  • 시스템을 테스트 할때 크게 3가지 방법으로 나눌 수 있습니다.
  • 전체 테스트 비중을 아래와 같은 수치로 구현하는 것이 권장됨
  • E2E(UI) Testing - 10%
  • Integrating Testing - 20%
  • Unit Testing - 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이 가장 쉬우며 효과가 좋습니다.

[참고] Test Pyramid란?

 

3. Unit Test 장점

  • 유닛 테스트는 UI Test 또는 Integration Test 보다 테스트 비용이 싸다고 할 수 있습니다. 왜냐하면 UI Test는 백엔드 서버와 프론트를 연동하여 사람이 직접 테스트하지만, 유닛 테스트는 사람이 스크립트로 한꺼번에 자동으로 실행하기 때문입니다.
  • 또한, 유닛 테스트는 다른 테스트에 비해서 실행 속도가 매우 빠릅니다. 그래서 유닛테스트를 활용하면 하루에도 배포를 여러번 할 수 있어 개발 및 배포 속도에 중요한 영향을 주기 때문에 개발할 때 최대한 활용하는게 좋습니다.
  • 새로운 기능을 구현할때 유닛 테스트를 잘 작성해놓으면 중장기적으로 유지 보수가 쉬운 장점이 있습니다. 즉, 이전에 통과했던 테스트 집합을 가지고 버그를 찾기 위해서 이전에 테스트 되었던 유닛테스트를 반복하는것을 regression 테스트라고 하는데 유닛테스만 반복하면 되기 때문에 regression 테스트도 반복적으로 수행 할 수 있습니다.
  • 유닛테스트를 잘 짜놓으면 유닛테스트가 되었던 코드에서는 버그가 거의 발견되지 않고 대부분 버그가 발견되는 경우는 유닛테스트가 없어서 발생하는 경우가 많고 만약 사후에 발견된 버그에 대해서도 버그를 수정한 후 유닛테스트를 작성해놓으면 버그를 방지할 수 있습니다.

 

4. Test의 일반 원칙

Unit test를 구현할때 지켜야 하는 일반적인 원칙들은 다음과 같습니다.

  • 테스트 유닛은 각 기능의 가장 작은 단위에 집중하여, 해당 기능이 정확히 동작하는지를 증명해야 합니다.
  • 각 테스트 유닛은 반드시 독립적이어야 합니다. 각 테스트는 혼자서도 실행 가능해야하고, 테스트 슈트로도 실행 가능해야 합니다. 이 때, 호출되는 순서와 무관하게 잘 동작해야 합니다. 이 규칙이 뜻하는 바, 새로운 데이터셋으로 각각의 테스트를 로딩해야 하고, 그 실행 결과는 꼭 삭제해야합니다. 보통 setUp() 과 tearDown() 메소드로 이런 작업을 합니다.
  • 테스트가 빠르게 돌 수 있도록 만들기 위해 노력해야 합니다. 테스트 하나가 실행하는데 몇 밀리세컨드 이상의 시간이 걸린다면, 개발 속도가 느려지거나 테스트가 충분히 자주 수행되지 못할 것입니다. 테스트에 필요한 데이터 구조가 너무 복잡하고, 테스트를 하려면 매번 이 복잡한 데이터를 불러와야 해서 테스트를 빠르게 만들 수 없는 경우도 있습니다. 이럴 때는 무거운 테스트는 따로 분리하여 별도의 테스트 슈트를 만들어 두고 스케쥴 작업을 걸어두면 됩니다. 그리고 그 외의 다른 모든 테스트는 필요한 만큼 자주 수행하면 됩니다.
  • 지금 사용하고 있는 툴이 개별 테스트나 테스트 케이스를 어떻게 수행하는지 배우셔야 합니다. 모듈 안에 들어있는 함수를 개발하고 있다면, 그 함수의 테스트를 자주, 가능하다면 코드를 저장할 때마다 자동으로 돌려야 합니다.
  • 그날의 코딩을 시작하기 전에 항상 풀 테스트 슈트를 돌려야 합니다. 끝난 후에도 마찬가지입니다. 이 작업은 당신이 다른 코드를 망가뜨리지 않았다는 더 큰 자신감을 심어줄 것입니다.
  • 모두가 공유하는 저장소에다가 코드를 집어넣기 전에 자동으로 모든 테스트를 수행하도록 하는 훅을 구현하는 하는 것이 좋습니다.
  • 지금 한창 개발 중인데 그만두고 잠시 다른 일을 해야한다면, 다음에 개발할 부분에다가 일부러 고장난 유닛 테스트를 작성하는 것도 좋은 생각입니다.
  • 코드를 디버깅할 때 가장 먼저 시작할 일은 버그를 찝어내는 새로운 테스트를 작성하는 것입니다. 이런 일이 언제나 가능한 것은 아니지만, 이런 버그 잡이 테스트들이야말로 당신의 프로젝트에서 가장 가치있는 코드 조각이 될 것입니다.
  • 테스트 함수에는 길고 서술적인 이름을 사용하셔야 합니다. 테스트에서의 스타일 안내서는 짧은 이름을 보다 선호하는 다른 일반적인 코드와는 조금 다릅니다. 테스트 함수는 절대 직접 호출되지 않기 때문입니다. 실제로 돌아가는 코드에서는 square() 라든가 심지어 sqr() 조차도 괜찮습니다. 하지만 테스트 코드에서는 test_square_of_number_2()test_square_negative_number() 같은 이름을 붙여야 합니다. 이런 함수명들은 테스트가 실패할 때나 보입니다. 그러니 반드시 가능한 한 서술적인 이름을 붙여야 합니다.
  • 무언가 잘못되었거나 뜯어고쳐야만 할 경우, 괜찮은 코드에 테스트 셋이 있다면 당신이나 다른 유지보수 담당자들은 오류를 수정하거나 프로그램의 동작을 수정할 때 필시 그 테스트 슈트에 전적으로 의지할 것입니다.
  • 테스트 코드의 또다른 사용 방법은 새로운 개발자들을 위한 안내서로 쓰는 방법입니다. 이미 만들어져 있는 코드에서 작업해야할 경우, 관련 테스트 코드를 돌려보고 읽어보는 것이야말로 가장 좋은 시작점일 경우가 많습니다. 이렇게 테스트 코드를 돌려보면 어느 지점이 문제인지, 수정하기 어려운 곳은 어디일지, 막다른 골목은 어디일지를 발견하게 됩니다. 몇 가지 기능을 추가해야 한다면 가장 먼저 해야할 일은, 그 새로운 기능이 아직 돌아가지 않음을 확인할 수 있는 테스트를 붙여넣는 것입니다.

'TIL > 웹의 이해' 카테고리의 다른 글

HTTP  (0) 2022.08.31
[API] RESTful API  (0) 2022.08.14
AWS (Amazon Web Service)  (0) 2022.07.28
Git & Github  (0) 2022.07.02
웹 서비스의 역사와 발전  (0) 2022.06.27