# test
[테스트] Jacoco를 통한 코드 커버리지 측정
개요 현재 코드스쿼드 피드백 중에 종종 들은 말이 있습니다. > "코드 커버리지는 어느정도 되세요?" 이 질문이 들어올 때마다 저는 "아직 측정해보지 않았습니다."라는 답변을 할 수 밖에 없었는데요, 이번 글에서는 왜 코드 커버리지 측정이 필요하고 어떻게 측정을 수행했는지 작성해보려 합니다. 코드 커버리지가 뭔데! 코드 커버리지는 테스트코드가 실제 코드를 얼마나 실행했는지를 백분율로 나타내는 지표입니다. 코드 커버리지를 통해 작성된 테스트코드의 수가 충분한지 확인할 수 있습니다. 측정 기준 그렇다면 코드 커버리지는 어떤 기준으로 측정되는 걸까요? 측정 기준에는 다음과 같은 것들이 있습니다. 함수 커버리지 구문 커버리지 브랜치 커버리지 조건 커버리지 함수 커버리지 함수 커버리지는 프로그램 내의 각 함수가 한 번이라도 호출되었는지를 검사합니다. 위와 같은 foo, bar 함수가 있을 때 foo함수가 호출됐으면 함수 커버리
상태 검증과 행위 검증
상태 검증 검증 대상 테스트 대상 객체의 상태를 검증한다. 객체의 상태는 객체의 속성 또는 반환 값 등을 포함한다. 주요 관점 테스트 후에 대상 시스템 또는 객체가 예상대로 변경되었는지 확인한다. 활용 사례 객체가 올바른 값을 반환하는지 예외가 올바르게 발생하는지 등을 검증하는 테스트에서 주로 사용된다. 장점 간단하고 직관적인 테스트 작성이 가능하다. 단점 내부 동작 방식이나 상호 작용에 대해 검증하지 않는다. 행위 검증 검증 대상 테스트 대상 객체의 행동을 검증한다. 객체의 행동은 메서드 호출, 이벤트 발생 등을 포함한다. 주요 관점 테스트 도중에 대상 시스템 또는 객체가 어떤 행동을 하는지 확인한다. 활용 사례 어떤 메서드가 어떻게 호출되는지 몇 번 호출되는지 등을 검증하는 테스트에서 주로 사용된다. 장점 객체 간의 상호 작용 및
테스트 @Transactional? @Sql? 선택에 대한 내 생각
테스트 Transactional 어노테이션 → Sql 어노테이션 적용 계기 현재 우리팀은 매 테스트마다 상관관계를 미치지 않기 위해, @Transactional 어노테이션을 이용하여 실제로 db에 저장하지 않고 롤백하는 방법을 채택했다. 하지만 실제 인수테스트에서는 Random Port를 이용하여 서버를 띄우는데, 클라이언트와 서버가 서로 다른 쓰레드에서 실행된다고 한다. (참고 : https://tecoble.techcourse.co.kr/post/2020-09-15-test-isolation/, https://velog.io/@jhp1115/1주차-인수테스트-코드에서의-팁) 따라서 @Transac
Localstack
Localstack이란? AWS API 를 시뮬레이션 해주는 프레임워크 도커 컨테이너 형태로 제공되며, AWS REST API 스펙에 맞는 모킹 http 서버를 실행 Ref : Overview Localstack 지원하는 서비스 Localstack은 Pro 버전과 Community 버전으로 나눠져 있으며 무료로 제공하는 서비스는 아래 Kinesis, DynamoDB, DynamoDB Streams, S3, Lambda, SNS, SQS, Redshift, Elasticsearch Service, SES, Route53, CloudWatch, SSM, SecretsManager, STS, IAM, EC2, KMS 등등 전체 서비스 목록 : [AWS Service Feature Coverage ](https://docs.localstack.cloud/user-guide
테스트 코드에 대한 오해와 편견
단위 테스트의 ‘단위’는 무엇인가?? 내가 자주 보는 마틴 파울러 아저씨의 블로그에 다음과 같은 글이 있다. > So there's some common elements, but there are also differences. One difference is what people consider to be a unit. Object-oriented design tends to treat a class as the unit, procedural or functional approaches might consider a single function as a unit. But really it's a situational thing - the team decides what makes sense to be a unit for the purposes of their understanding of the system and its testing. Although I start
[NestJS] Test
정적 테스트 코드를 수행하지 않고 검증하는 방법이다. 동료에게 code review 를 받는 것도 일종의 정적 테스트라고 할 수 있다. 동적 테스트 코드를 직접 실행해보며 검증 test case 작성법 TDD Test-driven development, TDD 는 개발자라면 한번쯤은 들어봤을 법한 말이다. 이는 test code 를 먼저 작성하고, 이를 기반으로 실제 code 를 작성해나가는 방법론이다. BDD behavior-driven development, BDD 는 Given / When / Then 스타일로 test 를 진행한다. unit test E2E ( end-to-end ) test 사용자의 행동을 코드로 작성 Jest 를 이용한 unit test test code 의 파일명은 .spec.ts 로 끝나야한다. Nest CLI 를 사용하면 .spec.ts 파일이 자동으로 생성된다.
[ZIO] .conf 변수 불러오기 - Config
개요 프로젝트를 하다 보면 API Key와 같은 민감한 정보들을 따로 관리하는 파일에 저장하고 앱에서 불러와 사용하는 경우가 있다. 테스트 코드에서 이를 불러오는 테스트를 작성해 보았다. 1. 테스트 코드 내에 직접 세팅하기 위의 코드에서 ConfigProvider 를 test suite 에 provideLayer 를 통해 제공해 준다. ConfigProvider 는 .fromMap() 메서드에 Map 형태로 세팅해서 사용할 수 있다. 2. 파일에서 불러오기 >프로젝트 내의 각 경로에 위와 같이 .conf 파일을 준비해둔다. 테스트코드를 보면 config 값을 찾는 순서는 아래와 같다. configProvider 에 지정해 둔 대로 "conf/application.conf" 에서 먼저 값을 찾는다. 없으면 "test/resources/application.conf" 에서 값을 찾는다. 없으면 "main/resources/appl
[TEST] 테스트에 대하여
✅ 소프트웨어 테스트 테스트의 필요성? 컴퓨터를 통해서 실행하기에 사람이 실행하는 것보다 빠르다. 정해진 스크립트에 따라 일관성있게 동작하기에 사람이 테스트 할 경우 발생할 수 있는 휴먼에러(오타 등 사람이 일으키는 에러)를 기피할 수 있다. 기능에는 변경이 없으며 더 나은 코드로 변경하려는 의도를 가진 Refactoring을 하려면 test는 필수다. refactoring을 하고 기능에 이상이 없는지 확인을 하려는 이유이다. 소프트웨어 테스트 종류 Unit test >유닛 테스트는 개별 함수, 메서드, 클래스, 컴포넌트 등의 동작을 테스트한다. 제일 간단한 형태의 테스트로 실행하는데 가장 적은 비용이 들어서, 가장 빈번하게 수행할 수 있는 테스트이다. Integration test >통합 테스트는 두개 이상의 모듈이 결합해서 동작을 잘 수행하는지에 대한 테스트이다. 컴포넌트가 Redux등의 상태관리 라이브러리와 통합했
첫 테스트 코드 적용기
인프런에서 테스트 코드 관련 강의를 듣고 '테스트가 이런것이구나' 를 간접적으로 체험했지만 직접적인 체험을 원했던 저는, 현재 진행중인 프로젝트의 일부 도메인에 테스트를 적용 해봤습니다. 기존의 개발방식 백엔드에서 DB 로직을 작성하고, 서비스 로직, 컨트롤러 로직 순으로 작성하고 나면 하나의 API가 만들어집니다. > DB -> 서비스 -> 컨트롤러 => API 완성! 위와 같이 한번에 원큐로 완성되면 정말 좋겠지만, 저같은 경우는 그렇지 않더군요. > DB -> 서비스(어라? 파라미터 뭔가 모자른데?) -> DB -> 서비스 -> 컨트롤러(파라미터 또 모자란다..) -> 서
[Spring] 보다 빠른 테스트를 위해 컨텍스트 캐싱하기
최근 TDD를 기반으로 한 단위 테스트, 통합 테스트 등 테스트 코드를 작성하는 것에 대한 열망이 커져 다양한 자료나 문서를 찾아보고, 강의를 들으며 공부하고 있다. 그런데, 사이드 프로젝트의 계층별로 테스트 코드를 작성한 후, 테스트를 실행해보니 스프링 컨텍스트가 여러 번 실행되고 있었다. 이를 통해 컨텍스트가 새로 띄워질 때마다, 즉 서버 실행 횟수가 많아질수록 테스트 속도의 차이가 나게 된다는 것을 알게 되었다. 그래서 어떻게 서버 실행 횟수를 줄일 수 있을까? 라는 고민을 통해 테스트가 실행되는 환경을 통합하여 컨텍스트 캐싱을 통해 테스트의 속도를 더 빠르게 개선할 수 있었다. 이번 글에서는 이 과정을 간단히 기록해보려 한다. 👀 스프링 컨텍스트의 실행 횟수는? 먼저 작성한 테스트 코드의 구성을 간단히 살펴보자. > - Presentation Layer(Controller): @WebMvcTest를 이용해 **
[Spring] 🌱 Junit5의 여러가지 기능
개인 프로젝트를 진행하면서 JUnit5를 활용한 단위테스트를 공부해보고 있는데 여러가지 기능들을 정리해 놓으려고 합니다. 🌱 Junit5 자바 개발자가 사용하는 테스팅 기반 프레임 워크를 의미합니다. JUnit 5는 자바 8 이상부터 사용 가능합니다. JUnit5의 어노테이션들중 일부를 하나씩 살펴보려 합니다. @Test @Test 어노테이션을 추가함으로써 테스트 메소드임을 선언할 수 있습니다. @BeforeAll, @AfterAll @BeforeAll을 통해 모든 테스트 코드가 실행되기 전 최초로 수행할 코드를 정의할 수 있고, @AfterAll을 통해 모든 테스트 코드가 종료된 이후 실행할 코드를 정의할 수 있습니다. 
jest 여러가지 비교 함수
toBe() 기본형을 비교할 때 가장 많이 사용. (두 값이 같은지 비교) 비교 대상이 기본형 : 두 원시 값이 같은지 object : 같은 오브젝트에 대한 참조 인지 비교 toEqual() 비교 대상이 기본형: 두 원시 값이 같은지(toBe와 동일) object : 재귀적으로 프로퍼티를 비교하며 깊은 비교를 수행 → 참조하는 오브젝트가 다르더라도 같은 프로퍼티에 같은 값이 있다면 성공. → 다만 추가적인 프로퍼티가 있는 경우 fail이 되지만 추가적인 프로퍼티가 undefined라면 테스트를 통과한다. toStrictEqual() 이름 그대로 일반적인 Equal 보다는 훨씬 엄격한 Equal 동작과정은 toEqual과 같게 깊은 비교를 한다. 기존과는 다르게 특정 요소에 undefined가 나오는 것을 허용하지 않음. toMatchObject() 비교할 오브젝트가 주어진 오브젝트의 부분집합인지를 비교. toStrictEqua
안녕 VELOG?
학부 3학년 2학기에 시작하는 것은 늦었지만 뭐라도 해야할 것 같아서 오늘부터 시작해볼 것이다. 기록할 내용은 학부에서 배우는 내용을 정리하는 것부터 시작해서 따로 공부하는 기술스택들을 정리할 것이다.
TDD
TDD(Test Driven Development)의 목적 작동하는 깔끔한 코드 과정 1) 원하는 기능이 정상적으로 수행한다는 것을 증명할 수 있는 테스트를 리스팅한다. '재생버튼을 누르면 노래가 나오는 기계'정도만 적어도 될 것 같다. 이에 대한 테스트 코드는 2.1에서 작성 2) 1번과정에서 도출한 테스트를 작성한다. 2.1 - 실패하는 테스트로 만든다. (Red) 처음에는 컴파일조차 안되니 Stub같은 개념을 활용하자. 2.2 - 일단 빨리 '성공'하게 만든다.(Green) 몇 분 정도 걸릴 것 같으면 일단 중단하고 원래 문제로 돌아가기 2.3 - 올바르게 만들기(리팩토링) 오퍼레이션은 변하지 않고 내부만 수정, 중복을 제거하는 과정이며 의존성으로 인한 단점이 사라지게 된다. 상수같은 것을 변수로 변환하는 과정 2.4 - 2번과정에서 나온 예기치 못한 문제들은 리스트에 계속 기입
정적테스트
Intro > 이번 프로젝트를 진행하면서 CodeMetrics 를 사용해서 SonalLint 를 적용하여 코드의 복잡도를 최대한 낮추면서 작업을 해왔다. 초록색이 아니면 수정하려고 했고 초록색이여도 EveryThing Is Cool! 이 보이지 않으면 뭔가 수정을 해야하나 고민하면서 코드를 작성했다. 1차 MVP 가 끝난 지금 제대로 코드를 돌려보았다. 결과 Check1 > 버그가 발생한 곳을 찾아보았다. UserController 에서 Null 체크를 하지 않아서 발생한 버그가 많았다. 이부분은 코드리뷰에서 말씀드리긴 했었는데 개인사정이 바쁘신지 아직 해결되지 않은것같다. 내 파트가 아니여서 함부로 건드릴수는 없지만 내가 담당한 부분에서의 버그는 0 이라 다행이였다. Check2
FastAPI 에서 pytest를 통한 서버 테스트 코드 작성
FastAPI를 통해서 API를 개발하는데 있어서 postman이나 swagger를 통해 테스트를 직접 수동으로 하는 것이 작업량이 많이 질 수록 테스트할 양이 많아지기 떄문에 불편함을 느꼈다. 그래서 이번 개발하는데 있어서 통합테스트 코드를 작성함으로써 개발시간에 좀 더 집중할 수 있게끔 하고자 파이썬에서 사용하는 테스트툴에 대해서 공부 해보도록 한다. 기본세팅 필요 모듈들 설치 pytest: Spring의 JUnit과 같이 파이썬에서 가장 대중적인 테스팅 프레임워크 pytest-asyncio: 비동기 코드를 테스트하기 위한 모듈 httpx: 최신 python 비동기 기능을 지원하는 http 클라이언트 라이브러리, requests 라이브러리와 유사한 API를 제공하지만, 동기/비동기를 모두 지원함 Spring에서는 RestTemplate, WebClient와 유사 폴더 구성 기본적으로 실제 app 폴더와 test폴더로 구성된다. 폴더구조는 일관성을
[Java Spring] Test Code에서의 BeforeEach 사용 주의점
다음 테스트코드에서 "올바른 대댓글 형식의 대댓글 저장" 테스트코드가 실패하는 이유를 직접 실행해보지 않고도, 알 수 있는 사람이 되고 싶다..! 왜 안되는지 읽어봤으면 좋겠다 !! 힌트 : PostgreSQL serial type 문제는 @BeforeEach때문이다. @BeforeEach로 매번 테스트 DB (나의 경우에는 인메모리 H2) 에 Comment를 추가한다. DB에는 serial 형태로 새로운 Comment 가 table에 들어올때마다, 알아서 PK값이 증가되면서 table에 추가된다. 전체 테스트 코드를 실행하면서 테스트 메서드를 매번 실행할 때마다, DB에 Comment 정보가 하나씩 생성됨을 잊지 말아야한다. 내가 앞서서, Comment 데이터중 1번 PK값을 가지는 Comment를 삭제하는 테스트 코드를 추가하였기 때문에, 전체 테스트중 "올바른 대댓글 형식의 대댓글 저장" 메서드에서 대댓글 달 댓글 정보가 없으니 테스트에 실패하는 것이다
[Java Spring] Test Code에서의 @Sql 어노테이션의 문제점
이렇게 했을 때의 문제점이 무엇일까? 바로 모든 메서드에 @Sql 어노테이션이 동작한다는 점이다. @Sql 어노테이션에 포함되어있는 Sql문은 이렇게 되어있어서 매 메서드마다 해당 Sql을 실행하면 중복 오류가 뜰 수 밖에 없다. 이를 해결하기 위해서는 다음처럼 @BeforeAll 어노테이션이 담긴 메서드에 ScriptUtils를 활용하여 작성해야 한다. 스택오버플로우의 도움을 좀 받았다.
[Java Spring] 내가 정한 테스트 코드의 목적성을 잃지 말자
나는 지금 Repository 계층 (Persistence Layer)의 단위테스트 (인메모리 DB를 띄워서 사실상 통합테스트 느낌이지만.. 결과적으로 서비스계층과의 결합성을 끊어냈으므로 단위테스트느낌이라고 생각했다)를 하고 있었다. 하지만 저 위에 테스트코드에서 잘못 생각했던 부분이 있었다. 바로 @WithMockCustomUser()이 부분이다. 왜 잘못되었을까? 나의 repository 관련 실제 구현코드는 다음과 같다. Repository 계층에는 딱 DB와 관련된 내용만 들어가야만 했다. 그렇다면 MockUser 테스트를 할 필요가 없었다. 왜냐하면, 진작 Service 계층(Business Layer)에서 해당 코드를 포함하였기 때문에, repository 테스트를 하는데 굳이 authentication 객체의 mocking이 필요가 없기 때문이다.
탐색적 테스팅 - 1. Test charter란 무엇일까?
앞으로 몇개의 포스팅에 걸쳐 관련 책의 요약 및 실무에서의 경험을 토대로, 탐색적 테스팅에 관련된 포스트를 기재하고자 합니다. 오늘은 주로 탐색적테스팅을 진행할때 많이 작성하는 테스트 차터에 대해 기재해봅니다. What is the Test charter? > A test charter is a concise statement that defines the scope, objectives, and strategy of a test session. It typically includes information such as the target area or feature, the test idea or question, the resources and tools needed, the risks and a