02.18 Spring Test
2023. 2. 18. 14:13ㆍ개발일지
버그(bug)
- 소프트웨어가 예상하지 못한 결과를 내는 것이며, 버그는 '소스 코드'나 '설계과정에서의 오류' 때문에 발생합니다.
개발 코드 배포 전, 버그를 (최대한 많이)찾아내는 법 - 테스트
블랙박스 테스팅
소프트웨어 내부 구조나 동작원리를 모르는 블랙박스와 같은 상태에서, 즉 웹 서비스의 사용자 입장에서 동작을 검사하는 방법입니다.
- 장점
- 누구나 테스트가 가능합니다. (개발자부터 디자이너, 베타 테스터 혹인 사장님등등)
- 단점
- 기능이 증가될 수록 테스트의 범위가 증가합니다.
- 시간이 갈수록 테스트하는 사람이 계속 늘어나야함
- 테스트 하는 사람에 따라 테스트 퀄러티가 다를 수 있습니다. (QA 직군이 있는 이유)
- 기능이 증가될 수록 테스트의 범위가 증가합니다.
개발자 테스트
개발자가 직접 "본인이 작성한 코드"를 검증하기 위해 "테스트 코드"를 작성합니다.
- 장점
- 빠르고 정확한 테스트가 가능합니다. (예상 동작 VS 실제 동작)
- 테스트 자동화가 가능합니다.
- 배포 절차 시 테스트 코드가 수행되어 동작을 검증합니다.
- 리팩토링이나 기능 추가를 할 때 더욱 편리합니다.
- 단점
- 개발 시간이 오래 걸립니다.
- 테스트 코드를 유지보수하는 비용
JUnit을 이용한 단위 테스트
단위 테스트
- 프로그램을 작은 단위로 쪼개서 각 단위가 정확하게 동작하는지 검사하고 이를 통해 문제 발생 시 정확하게 어느 부분이 잘못되었는지를 재빨리 확인할 수 있게 해줍니다.
버그 발견 시간이 늦어짐에 따라 비용이 기하급수적으로 커지는 걸 알 수 있습니다.
- Development : 개발
- Unit Tests (단위 테스트) : 개발자 테스트
- QA Testing : 블랙박스 테스팅, 주로 QA 팀이 Production 환경과 유사한 환경 (Stage)에서 테스팅
- Production : 실 서비스 운영 환경
개발 - 단위테스트 - QA - Production(배포)로 이루어졌다고 생각해봤을 때, 다음 단계를 가기 위해서는 이전 단계를 거쳐야 합니다. QA 중에 버그가 발견되었으면, 다시 개발, 다시 단위테스트, 다시 QA를 진행해야 하며, 심지어 운영 환경이라면 기존의 절차를 모두 거치고, 유저들에 대한 보상까지 필요 할 수 있습니다.
TDD (Test-Driven Development)
- 테스트 코드를 먼저 작성하고 실제 동작하는 코드를 개발하는 순서로 개발하는 개발 방법론입니다. 찬반의 의견이 아직도 많긴 하지만, 좋은점만 취할 수 있다면, 테스트코드를 먼저 작성하는 개발은 적어도 위와 같은 싸이클에서는 매우 효율적입니다.
(설계 → 개발 → 테스트에서 설계 → 테스트 → 개발 순서로)
Given - when - then Pattern
- 테스트 코드를 작성하는 가장 대표적인 방법론입니다.
Given - 준비, When - 실행, Then - 검증
'개발일지' 카테고리의 다른 글
02.19 ORM / SQL / MVC (0) | 2023.02.20 |
---|---|
02.18 Transaction (0) | 2023.02.18 |
02.18 OAuth2 (0) | 2023.02.18 |
02.17 Spring Security (2) (0) | 2023.02.17 |
02.17 Spring Security (1) (0) | 2023.02.17 |