# kotest
[Spring/Test] Kotest @Transactional
최근 Kotest로 테스트 코드를 작성하면서, 코틀린 특유의 가독성을 즐기며 테스트를 작성하고 있었습니다. JUnit에서와 마찬가지로 @Transactional을 이용하여 테스트 데이터를 teardown 하는 작업을 진행했습니다. 그런데, 우연치 않게 DB를 확인하다가, 테스트 데이터가 그대로 남아있는 것을 보게 되었습니다. 오늘은 왜 @Transactional이 작동하지 않았는지 살펴보겠습니다. 한 줄 요약 SpringExtension을 사용하자 @Transactional Transaction의 개념이 생소하신 분은 Transaction에 대해 잘 정리된 블로그를 먼저 보시는 것도 좋을 거 같습니다. 우선 간단하게, 테스트 코드에서의 @Transactional에 대해 살펴보겠습니다. 테스트에서 @Transactional은 편의를 위해 사용되곤 합니다. 일반적으로 테스트를 진행
Kotest와 BDD, 테스트 코드 작성하기 전 읽어두면 좋을 자료들
해당 글은 BDD(Behavior Driven Development) 방식의 테스트 스타일과, Kotest 프레임워크의 BehaviorSpec을 사용하는 것으로 가정하고 작성하는 것을 미리 알려드립니다. Cucumber의 BDD 작성 가이드 일단 BDD 방식으로 테스트 코드를 짜겠다고 마음 먹었는데 테스트 문장은 어떻게 구성해야 맞는 걸까? 고민하다가 아래 글을 참고하게 되었다. 참고로 Cucumber는 BDD 방식의 테스트 프레임워크이다. 테스트 프레임워크는 다르지만 어쨌든 테스트 방법은 같으니까 참고해도 좋을 것 같다. > 3인칭 한 명의 시점으로 작성하라 1인칭(나), 2인칭(그/그녀) 등 1,2인칭 시점을 쓰면 상황적 제한이 생길 수 있다. 3인칭 시점으로 보편화하여 적는 것이 포인트 시나리오는 나를 포함하여 소프트웨어를 사용하는 ‘사용자’를 설명하기 때문에 개인적으로 User(유저)
Kotest, MockK 에 관하여
본 포스팅은 고품격 Kotlin 개발: 테스트 코드를 우아하게 작성하는 방법을 보고 정리한 내용입니다. 1️⃣ 단위 테스트 코틀린으로 테스트 코드를 작성하는 것은 재미있지만, JUnit 및 Mockito 등과 같은 기존 자바 라이브러리 및 프레임워크를 사용하여 테스트하기 때문에, 동시에 코틀린스러운 테스트 코드를 작성하는 것은 어렵습니다. 코틀린의 특징 중 하나인 읽기 쉽고 간결하다는 장점을 활용하여 테스트 코드를 작성하고 싶습니다. 역따옴표(`)로 묶인 함수 이름은 한글과 공백으로 표현할 수 있다. 예외 테스트는 JUnit5의 assertThrows 및 *assertDoesNotThrow
Kotest Test Style
https://kotest.io/docs/framework/testing-styles.html Fun Spec String Spec Should Spec Describe Spec Behavior Spec Word Spec Free Spec Feature Spec Expect Spec Annotation Spec @BeforeAll / @BeforeClass @BeforeEach / @Before @AfterAll / @AfterClass @AfterEach / @After
Kotlin에서의 BDD (Behavior Driven Development)
들어가며.. > 최근 프로젝트 팀원이 추천해준 영상을 보고 BDD 라는 것을 처음 알게 되었다. 해당 영상에서는 kotest와 mockk 테스팅 툴을 사용하여 TDD와 BDD의 차이점을 잘 설명해주고 있다. 최근 Kotlin 언어를 공부하고, Kotlin + Spring 조합으로 개발하는 것에 관심을 가지고 있다보니 꽤 흥미로웠다. > > 영상 : https://tv.kakao.com/channel/3693125/cliplink/414004682 예제코드 : https://github.com/harry-jk/ifkakao-2020-code BDD (Behavior Driven Development) 란 TDD에서 파생된 개발 방법론 개발자와 비개발자간의 협업 과정을 녹여낸 방법 사용자의 행위를 작성하고 결과를 검증한다. BDD로 테스트 코드를 작성하면, 설계 역시 행위 중심이 되는 도메인 기반 설계가 된다. TDD 에서 T가
Kotlin Test
테스트 코프링 프로젝트의 테스트를 구성해보았다. 테스트를 하면서 사용한 패키지들은 아래와 같다. Kotest Mockk Fixture(faker, fixtureMonkey, kotlinFixture) fixture를 사용할 때 위 처럼 세가지 종류를 사용해봤는데 결론적으로 현재는 kotlinFixture를 사용하고 있다. fixture들을 사용하면서 느낀 점들과 갈아탄 이유들을 정리하려고 한다. Prerequisite 예시를 위해서 다음과 같은 엔티티가 있다고 하자. Java Faker faker는 예시이기는 하지만 아래와 같은 방식으로 사용하였다. 이렇게 사용하다보니 몇 가지 불편한 점이 생겼는데 다음과 같다. 프로젝트를 멀티 모듈로 관리하게 되면서 fixture 관련 함수들을 불러오기 위해 `te
Kotest ClassNotFoundException
Kotest 최근에 포트폴리오를 같이 만들었던 형 누나들과 만나서 스터디와 함께 포트폴리오 프로젝트를 싹 다 뜯어고쳐 만들자고 설득해서 프로젝트를 시작했다. 백엔드는 Kotlin + Spring으로 결정하고 나는 최근에 TDD에 빠져서 테스트 코드를 작성하는데 기존의 Junit5를 코틀린에 사용하는게 불편해 사용하기 편한 코틀린 테스트 라이브러리가 없나 찾다 Kotest를 발견했다! 기존의 Junit처럼 @Test를 사용하는 방식부터 다양한 테스트 코드를 지원해 흥미가 생겨 바로 적용했다. Kotest Plugin build.gradle.kts에 적용하고 사용하는데 도저히 실행시키는 버튼이 나오질 않는다. 찾아보니 인텔리제이 기존 kotest를 실행하기 위해서는 인텔리제이 플러그인에서 Kotest를 설치해야 한다. 그렇게 플러그인도 설치하고 실행하니 ClassNotFoundException ClassNotFoundException 예외가 생긴다 그래서
[Kotlin] Kotest로 코틀린 UnitTest 해보기
테스트 코드란 마치 유X브 프리미엄 같다. 한 번 쓰면 끊을 수가 없어 요즘 어느 회사던 채용 공고를 살펴보면 Unit Test 및 UI Test 작성 경험이 있는 사람을 우대 해주는 곳이 많다. 그렇다면 왜 Why 테스트 코드 작성 경험이 있는 사람을 우대해주며 테스트 코드를 작성해야 하는 이유는 무엇일까..?🤔 우선 안드로이드에서 기능을 구현하고 구현한 기능을 테스트 해보려면 다음과 같은 순서로 테스트를 진행한다. > 1. 기능을 구현하는 코드 작성 그 기능이 정상적으로 작동하는지 AVD나 디바이스에서 빌드하여 기능 확인 에러가 발생하면 코드 수정 후 다시 빌드하여 확인 위와 같은 순서를 반복하게 되는데 프로젝트 규모가 작다면 위와 같은 순서로 반복해도 그렇게 크게 차이가 나지 않는다.. 그러나 But 프로젝트의 규모가 커진다면??!! 앱을 빌드하는 시간 + UI에 입력하여 테스트하는 시간이 더해져 많은 시간을 필요로 할 것이다. 현재
PBT로 FP 법칙 확인해보기 - Applicative
Applicative Monad를 구성하는 기본수단이 unit과 flatMap이었다면, Applicative는 unit과 map2를 기본수단으로 하는 특질이다. applicative 특질은 그 이름이 시사하는 것처럼 unit + map2 말고도 unit + apply 를 기본수단으로 가지도록 할 수도 있다. 이 사실은 곧 map2는 unit과 apply를 이용해서 구현할 수 있고, apply 또한 unit과 map2를 이용해서 구현할 수 있다는 것을 뜻한다. PBT로 Applicative 법칙 확인해보기 왼쪽, 오른쪽 항등법칙 map2(unit(()), fa)((_, a) => a) == fa map2(fa, unit(()))((a, _) => a) == fa kotlin syntax로 표현한 왼쪽, 오른쪽 항등법칙은 각각 아래와 같다. 그리고 이를 검사하는 pbt 기반 테스트 코드는 다음과 같다. nelArb는 비어있지 않은
PBT로 FP 법칙 확인해보기 - Monad
Monad Functor가 map을 가지고 있는 자료 구조들을 일반화한 특질인 것 처럼, Monad는 unit과 flatMap을 가지고 있는 자료구조를 일반화한 특질이다. Monad 만들기 arrow의 kind를 이용해서 Functor를 만들었던 것처럼 monad도 비슷한 방식으로 인터페이스를 정의해볼 수 있다. 한가지 흥미로운 점은, Functor에 등장하는 map 함수는 Monad의 unit과 flatMap을 이용해 아래와 같이 구현할 수 있다는 점이다. map(f) == flatMap(a => unit(f(a))) 그러므로 Monad 인터페이스는 Functor 인터페이스를 상속하도록 하고, map 함수에 대해서는 default method를 제공해줄 수 있다. 그리고 Functor에서 했던 것과 같이 다양한 타입 생성자에 대해 Monad 인스턴스를 작성할 수 있다. PBT로 Monad 법칙 확인해보기 결합법칙 모든 Mon
PBT로 FP 법칙 확인해보기 - Functor
Functor 우리는 함수형 프로그래밍 패러다임을 지원하는 많은 언어에서 다양한 자료 구조에 대해 map 함수를 지원하는 것을 알고 있다. 이러한 이른바 "map 함수를 구현하는 자료 구조"를 일반화한 특질을 Functor라고 부른다. Functor 만들기 functor는 어떤 형식(type)에 대한 것이 아니라 형식 생성자(type constructor)에 대한 것인데, 코틀린에서는 이 형식 생성자를 generic하게 표현하는 방법을 지원하지 않는다. 대표적인 함수형 언어인 스칼라에서는 상위 형식 생성자(higher kinded type)라고 불리는 개념을 기본 syntax로 제공하는데, 코틀린에서 이 higher kinded type을 표현하기 위해서는 코틀린 함수형 라이브러리인 arrow의 힘을 빌려야 한다. higher kinded type을 표현하기 위해 arrow에서 제공하는 Kind 형식을 사용해 Functor 인터페이스를 아래와 같이 작성할 수 있다.
PBT로 FP 법칙 확인해보기 - 모노이드
깃헙 코드 바로가기 모노이드 하나의 모노이드는 다음과 같은 요소들로 구성된다. 어떤 형식 A A 형식의 값 2개를 받아서 하나의 값을 산출하는 결합적 이항 연산 op. 이 연산 op에 대한 한등원 zero. 그리고 op는 아래와 같은 결합 법칙을 만족해야 한다. 그리고 항등원 zero는 아래 법칙을 만족한다. 모노이드 만들기 위에서 설명한 모노이드의 개념을 코드로 구체화시켜보면 아래와 같은 인터페이스로 표현할 수 있다. 그리고 이 인터페이스를 상속하는 다양한 모노이드를 만들 수 있다. PBT로 모노이드 법칙 확인하기 항등법칙과 결합법칙은 각각 아래와 같은 코드로 표현될 수 있다. 그리고 이를 PBT 기반으로 테스팅하는 함수로 한번 더