테스트 코드
어플리케이션의 복잡도가 증가하면서
테스트 코드의 중요성도 함께 증대되었다
요즘에는 TDD 등이 유행하기도 하며
만물 테스트론도 있었고
프론트 테스트 무용론도 있었다
나는 중립이라기 보다는
모든 영역에 테스트가 필요한가에 대한 의문은 있었다
쓸 곳과 안써도 되는 곳을 구분하는 것이 좋지 않을까
라는 생각이다
코드 구조가 조금 변경되기라도 하면 혹시 테스트 코드도 함께 변경되어야하거나 하는 일이 없다면
모든 곳에 짜놓으면 도움이 될 것 같다
테스트 코드는 주 목적인 테스트의 용도 외에도
함수형 프로그래밍 처럼 코드의 전체를 보지 않아도
해당 코드가 어떤 기능을 하는 것인지
대략적으로 파악할 수 있고
객체지향에서 처럼 인터페이스 역할도 할 수 있는 것 같다
뭐 둘 다 역할은 비슷하지만..
테스트에는 크게 정적 테스트와 동적 테스트가 있다
정적 테스트
코드 품질을 향상 시키는 첫 번째 단계로 정적 분석 도구를 사용하는 것이다
정적 분석은 코드를 작성할 때 오류가 있는지 코드를 확인하는 것으로 실행은 하지 않는다
- 린터: 코드를 분석하여 코드 내 일반적 오류를 포착하고 실수를 피하는데 도움이 된다
코드 스타일을 일관성 있게 작성하는데에도 유용하다 - 타입 유형 검사: 전달되는 데이터 타입 유형을 검사하여 정의된 타입을 사용하고 있는지 검사
ESLint 와 TypeScript 를 잘 사용하자..
동적 테스트
동적 테스트에는 크게 단위 테스트, 통합 테스트, 인수 테스트(Acceptance Test), E2E 테스트
등이 있다
테스트를 위해 테스트 코드를 작성해야 하고 테스트할 코드를 실행하여
원하는 바에 맞게 동작하는지 확인한다
프론트에서 앱을 테스트하기 더 쉽게 하기 위해서는 앱의 View 영역을
비즈니스 로직과 상태에서 분리하는 편이 좋다고 한다
MVVM 패턴 등의 View 와 로직을 분리하는 패턴이 유행하는데에
테스트 코드가 일조한 것일지도 모르겠다
MVVM 패턴도 사용해보면서
코드 리팩토링과 함께 진행하면 더 좋을 것 같다
단위 테스트 (Unit Test)
테스트 대상 단위의 범위는 정확하게 정해져있지 않지만
클래스나 메소드 단위로 검증한다
코드의 기능 단위로 테스트하는 방법
TDD 와 함께 사용될 때 강력하다
통합 테스트 (Integration Test)
코드에 사용된 모든 영역에 대해서 묶어서 테스트 하는 방법
단위 테스트에서 발견하기 어려운 상호작용에 따른 버그 등을 찾을 수 있다는 장점이 있다
인수 테스트 (Acceptance Test)
인수 테스트는 시나리오 테스트로
비지니스에 초점을 둔다
E2E 테스트 (End To End - 종단간 테스트)
사용자 관점에서 테스트 하는 방법으로
개발 부터 사용자 까지의 End Point 끼리의 상호작용을 테스트 하는 것
위의 테스트들을 할 여건이 되지 않는다면 종단간 테스트만이라도 하는 편이 좋다
E2E 테스트를 통과한다는 것은 과정 중 모든 코드가 원하는 동작을 하고 있다는 뜻이기 때문
