21.10.09 TIL

테스트 코드 작성의 장단점

• 장점
  • 예상 동작과 실제 동작을 비교하여 빠르고 정확한 테스트가 가능하기 때문에 초기 개발의 디버깅이 쉬워진다.
  • 어플리케이션이 변경(기능 확장 또는 리팩터링 등)되더라도 올바르게 작동하는 지 확인할 수 있다.
  • 단위 테스트 자체를 어플리케이션에 대한 문서로 사용할 수 있다. 특히 잘 만든 테스트 케이스는 API 기능을 쉽게 파악할 수 있도록 도와준다.
  • 여러 빌드 도구들(maven, gradle 등)은 테스트 자동화 기능을 포함하고있다.
• 단점
  • 테스트 코드까지 작성해야하기 때문에 개발 시간이 오래 걸리게 된다.
  • 어플리케이션 변경 사항을 테스트 코드에도 적용해야 하기 때문에 테스트 코드를 유지보수하는 비용이 든다.

테스트 종류 별 (단위 테스트, 통합 테스트, E2E 테스트) 특징

• 단위 테스트

  프로그램을 작은 단위로 쪼개서 고립된 각 모듈이 정확하게 동작하는지를 검사한다.

  • 어디에서 문제가 발생했는지를 빨리 확인할 수 있기 때문에 디버깅 시간을 단축시킨다.
  • 코드 변경 뒤에도 기능이 제대로 동작하는지 검증해주기 때문에 프로그래머가 더 의욕적으로 코드를 변경할 수 있게 도와준다.
  • 통합이 간단하기 때문에 통합 테스트에 도움이 된다.

• 통합 테스트

  단위 테스트가 끝난 소프트웨어를 결합해 가며 시험 하는 방법이다. 단위 테스트가 끝난 모듈들을 좀 더 큰 단위의 집합으로 통합 구성한 후, 통합 테스트 계획에 따라서 테스트를 수행한다. 스프링 프레임워크에서는 @SpringBootTest 어노테이션을 제공하여 통합테스트를 제공한다.

  • 통합 테스트는 단위 테스트와 달리 개발자가 변경할 수 없는 부분까지 묶어 검증할 때 사용한다. (ex. 외부 라이브러리)
  • 단위 테스트에서 발견하기 어려운 버그를 찾을 수 있다.
  • 단위 테스트보다 더 많은 코드를 테스트하기 때문에 신뢰성이 떨어질 수 있고 어디에서 문제가 발생했는지 확인하기 쉽지 않다.

• E2E(End To End) 테스트

  사용자의 입장에서 사용자가 사용하는 상황을 가정하고 테스트 하는 것이다.

  • 일반적으로 웹이나 어플 등에서 GUI를 통해 시나리오, 기능 테스트 등을 수행한다.
  • 사용자에게 직접적으로 노출되는 부분을 점검한다.
  • 단위 테스트로 불가능한 사용자 관점의 테스트까지 가능하다.
  • Web 환경에서는 Selenium, Cypress, TestCafe 등의 E2E 테스트 프레임워크가 있다.

테스트 코드 장단점 참고 https://chorizzori.tistory.com/85 ,https://teamsparta.notion.site/Spring-3-b7b549fb59c04b65b763adacb2ace143#e38e330f21b240c19af230d538f9c7b2

단위 테스트, 통합 테스트, E2E 테스트 참고 https://tecoble.techcourse.co.kr/post/2021-05-25-unit-test-vs-integration-test-vs-acceptance-test/ https://medium.com/hbsmith/e2e-test-알아보기-3c524862469d

---

Maven

Maven은 내가 사용할 라이브러리 뿐만 아니라 해당 라이브러리가 작동하는데 필요한 다른 라이브러리들까지 관리하여 네트워크를 통해 자동으로 다운 받아준다.

Maven은 프로젝트의 전체적인 라이프사이클을 관리하는 도구이며, 많은 편리함과 이점이 있어 널리 사용되고 있다. 기존에는 Ant가 많이 사용되었지만 Maven이 Ant를 넘어서 더 많은 개발자들이 사용하게 되었고 비교적 최근에는 Gradle이 새롭게 나와 사용되고 있다.

Maven은 JDK설치와 같이 설치할 수 있다. 환경변수 잡아주고 하면 cmd에서 mvn –version을 통해 버전을 알 수 있고 설치가 가능하다. 설치는 메이븐 홈페이지 에서 할 수 있다.

Maven 에서는 미리 정의하고 있는 빌드 순서가 있으며 이 순서를 라이프사이클이라고 한다. 라이프 사이클의 가 빌드 단계를 Phase라고 하는데 이런 Phase들은 의존관계를 가지고 있다.

• Clean : 이전 빌드에서 생성된 파일들을 삭제하는 단계
• Validate : 프로젝트가 올바른지 확인학고 필요한 모든 정보를 사용할 수 있는 지 확인하는 단계
• Compile : 프로젝트의 소스코드를 컴파일하는 단계
• Test : 유닛(단위) 테스트를 수행하는 단계(테스트 실패시 빌드 실패로 처리, 스킵 가능)
• Package : 실제 컴파일된 소스 코드와 리소스들을 jar등의 배포를 위한 패키지로 만드는 단계
• Verify : 통합테스트 결과에 대한 검사를 실행하여 품질 기준을 충족하는지 확인하는 단계
• Install : 패키지를 로컬 저장소에 설치하는 단계
• Site : 프로젝트 문서를 생성하는 단계
• Deploy : 만들어진 Package를 원격 저장소에 release하는 단계

위에 9개의 라이프사이클 말고도 더 많은종류의 라이프사이클이 존재한다. 이를 크게 Clean, Build, site 세가지 라이프사이클로 나누고 있다. 각 단계를 모두 수행하는 것이 아니라 원하는 단계까지만 수행할 수도 있으며 test단계는 큰 프로젝트의 경우에 몇시간이 소요될 수도있으니 수행하지 않도록 스킵이 가능하다.

#Phase와 Goal

위에서 잠깐 언급했던 Phase는 Maven의 Build LifeCycle의 각각의 단계를 의미한다. 각각의 Phase는 의존관계를 가지고있어 해당 Phase가 수행되려면 이전 단계의 Phase가 모두 수행되어야 한다.

Maven에서 제공되는 모든 기능은 플러그인 기반으로 동작하는데 Maven은 라이플사이클에 포함되어있는 Phase마저도 플러그인을 통해 실질적인 작업이 수행된다. 즉 각각의 Phase는 어떤 일을 할지 정의하지 않고 어떤 플러그인의 Goal을 실행할지 설정한다.

Maven에서는 하나의 플러그인에서 여러작업을 수행할 수 있도록 지원하며, 플러그인에서 실행할 수 있는 각각의 기능을 goal이라고 한다. 플러그인의 goal을 실행하는 방법은 다음과 같다.

• mvn groupId:artifactId:version:goal(아래와 같이 생략가능)
• mvn plugin:goal

pom은 Project Object Model 의 약자로 이름 그대로 Project Object Model의 정보를 담고있는 파일이다. 이 파일에서 주요하게 다루는 기능들은 다음과 같다.

• 프로젝트 정보 : 프로젝트의 이름, 개발자 목록, 라이센스 등
• 빌드 설정 : 소스, 리소스, 라이프 사이클별 실행한 플러그인(goal)등 빌드와 관련된 설정
• 빌드 환경 : 사용자 환경 별로 달라질 수 있는 프로파일 정보
• POM연관 정보 : 의존 프로젝트(모듈), 상위 프로젝트, 포함하고 있는 하위 모듈 등

POM은 pom.xml파일을 말하며 Maven의 기능을 이용하기 위해 POM이 사용된다.