일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- 논리 메모리
- DFS
- DP
- queue
- Python
- BFS
- 코딩 테스트
- 백준
- OOP
- 스택
- 디바이스 입출력
- 자료구조
- integretion test
- java
- 유니크 키
- 파이썬
- 객체지향 프로그래밍
- 프로세스
- springboot
- 다익스트라
- 데드락
- OS
- stack
- 큐
- 캡슐화
- 백준 #
- unionfind
- 운영체제
- SW Expert Academy
- error
- Today
- Total
목록TestCode (3)
middlefitting
테스트 코드를 작성하다 보면 테스트 커버리지를 측정하고 싶은 경우가 생긴다. 측정을 넘어 테스트 커버리지에 제약을 걸어 새로 프로젝트의 커버리지를 높게 유지하고 싶다는 생각도 자연스럽게 생긴다. jacoco는 커버리지, 측정, 검증 도구로써 이런 고민을 해결해 줄 수 있다. 해당 글에서는 jacoco를 활용하여 단위 테스트와, 통합 테스트의 커버리지 측정 및 검증을 하는 방법을 알아보도록 한다. 환경은 스프링 부트, gradle 을 기준으로 한다. 우선 단위 테스트와 통합 테스트를 분리해서 측정하기 위해서는 해당 태스크가 분리되어 있어야 한다. 분리를 할 수 있는 방법은 아래의 글을 참고할 수 있다. https://middlefitting.tistory.com/103 스프링에서 단위 테스트, 통합 테스트..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/ON93p/btsCypWKVGJ/mEg92T8LJnrmOGePTzXv81/img.png)
스프링에서 테스트 코드를 작성하다 보면, 통합 테스트와 단위 테스트를 주로 작성하게 된다. 그런데 테스트 코드가 점점 많아지면서 관리에 어려움이 생긴다. 커버리지 측정에 있어 단위 테스트와 통합 테스트를 분리하고 싶은 경우도 생기고, 각각의 테스트를 분리해서 실행시키고 싶은 경우가 존재하는데 gradle에서 기본적으로 제공하는 Test 태스크는 모든 테스트를 한번에 실행시키기 때문에 파일의 구분이 어렵다. 근데 스프링과 JUnit에서는 당연히 해당 내용에 대한 해결책을 제시한다. 나와 비슷한 고민을 한 분들을 위해 gralde, JUnit, Spring에서 간단한 방법으로 단위 테스트와 통합 테스트를 구분하는 방법을 공유하고자 한다. 1) Tag 활용하기 @Tag 해결 방법은 아주 간단하다. JUnit..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/LueUG/btsCr62QtcW/s8wipgxQyLers1X3FjWQJ0/img.png)
테스트 코드가 중요하단 것은 개발을 공부하는 모두가 알고 있다. 그런데 생각보다 실천에 옮기기 어렵다. 실제로 학생으로써 개발을 공부하며 다양한 사이드 프로젝트에 참여해 왔지만, 테스팅 환경이 잘 구성된 경우는 없었다. 테스트 코드가 존재하더라도 이미 다 깨진 테스트 코드가 대부분이었고, 관리는 전혀 이루어지지 않았다. 테스트 코드는 잘 작성하지 않는 이유는 무엇일까. 이유는 다양하겠지만, 테스트 코드를 작성하는 시간이 아깝다고 느끼는 경우가 많은 것 같다. 기능 구현하기도 바빠서 테스트를 짤 시간이 없다는 생각이 대부분의 이유이다. 근데 기능 구현이 끝나도 테스트 코드를 잘 작성하지 않는다. 심지어 배포 이후에 버그가 펑펑 터지고 그걸로 고생하는 경우가 생겨도 테스트 코드를 작성하지 않는다. 이런 상황..