일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
29 | 30 | 31 |
- 클린아키텍처
- 코틀린
- 객체지향의사실과오해
- 개발서적
- TDD
- 추상화 설계
- 아키텍처
- 만들면서배우는클린아키텍처
- template
- 조영호
- 헥사고날아키텍처
- 개발방법론
- GrokkingFunctionalProgramming
- 스터디
- 유지보수
- Thymeleaf
- 책스터디
- 도메인 주도 개발 시작하기
- 이펙티브코틀린
- 테스트주도개발
- Spring
- Boot Legacy 차이점
- DDD
- Kotlin
- Java
- FP
- 테스트
- 계층형아키텍처
- 함수형프로그래밍
- web
- Today
- Total
김동형수 개발기
Grokking Functional Programming - 2부 12장 본문
Grokking Functional Programming - 2부 12장
김동형수 2023. 2. 6. 21:1012 기능적 프로그램 테스팅
이 장에서 배울 것입니다
- 예제를 제공하여 순수 함수를 테스트하는 방법
- 속성을 제공하여 순수 함수를 테스트하는 방법
- 모의 라이브러리를 사용하지 않고 부작용을 테스트하는 방법
- 테스트 기반 방식으로 새로운 기능을 개발하는 방법
이 책의 마지막 장은 가장 중요한 소프트웨어 엔지니어링 활동 중 하나인 테스트 에 할애됩니다 . 테스트는 유지 관리 가능한 소프트웨어를 작성하는 주요 방법 중 하나입니다. 이를 사용하여 프로그램이 요구 사항에 따라 작동하는지, 이전에 발견한 버그가 없는지, 외부 API, 서비스 또는 데이터베이스와 제대로 통합되는지 확인할 수 있습니다.
가장 편리한테스트할 함수는 단순 유형을 사용하는 순수 함수입니다.
이러한 비 IO함수는 일반적으로 중요한 비즈니스 로직을 나타냅니다.
이러한 함수에 대한 테스트는 작성하기가 매우 쉽습니다.
FP 테스트는 함수를 호출하고 출력을 어설션합니다.
속성 기반 테스트는 기능을 보다 비판적으로 보는 데 도움이 됩니다.
맞춤생성기
Gen
사용자 지정 생성기 사용
구현에서 버그 찾기 및 수정
예제에서 int 오버플로우 발생해서 Long 타입으로 변환한다.
궁극적인 목표는 구현이 요구 사항에 따라 올바르게 작동하는지 확인하는 것 입니다.
부작용이 있는 요구 사항 (즉, 외부 데이터 소스 및 읽기/쓰기 IO 작업이 필요한 요구 사항) 테스트에 진입하고 있습니다.
여기에는 적절한 요청 형식, 구문 분석 응답, API 제한, 성능과 같은 저수준 항목이 포함됩니다.
이러한 요구 사항을 충족하려면 두 가지 종류의 테스트가 필요합니다. 하나는 요청/응답 측면(읽기/쓰기 IO 작업이 외부 데이터 소스와 올바르게 통합되는지 여부)을 다루는 테스트이고 다른 하나는 사용 측면(데이터가 응답이 올바르게 사용됨).
- 서비스 데이터 사용 테스트 - 비즈니스 가치로 변환되는 방식을 포함하여 데이터를 가져온 후 애플리케이션이 데이터를 사용하거나 저장하기 전에 데이터를 준비하는 방식(외부 서비스 데이터는 우리가 테스트하는 문제가 아니기 때문에 여기에서 스텁할 수 있음).
- 서비스 통합 테스트 - 애플리케이션이 요청 형식을 지정하고 실제 서비스에서 응답을 올바르게 가져오는지 여부(데이터를 스텁할 수 없음 - 실제 서비스를 사용하여 테스트해야 함).
기능적 디자인 패러다임은 프로덕션 코드에서 아무 것도 변경하지 않고 특수 모킹 라이브러리 없이 두 종류의 테스트를 작성하는 데 도움이 될 것입니다.
서비스 데이터 사용 테스트
외부 정보 엑세스(DB, API 통신) 등을 할 때 IO(catseffect) 를 사용했는데 테스트코드 작성 시 데이터 검증을 위한 테스트에서는 IO.Pure를 사용해서 하드코딩한 데이터를 이용한다. ( 여기에 맞춤생성기를 곁드린다면 더 완벽해질 것 같다 )
서비스 통합 테스트
다시 말하지만, 동일한 규칙이 SQL 통합이나 기타 외부 서비스 또는 데이터 소스에 적용된다는 점을 기억하십시오.
서비스와의 통합은 단일 책임입니다.
이러한 격리된 통합 테스트를 너무 많이 사용하면 단점이 있습니다. 테스트 파이프라인이 상당히 느려질 수 있습니다 . 실제 서버를 사용하는 경우 프로세스 시작, 포트 열기, 들어오는 연결 대기 및 처리 등을 위해 더 기다려야 합니다. 함수를 호출하고 그 결과를 주장하는 것보다 훨씬 더 많은 작업입니다. 우리는 테스트 스위트를 설계할 때 그것에 대해 생각해야 합니다.
모든 것을 순수 함수와 불변 값으로 모델링하는 것의 좋은 점은 순수 함수와 불변 값으로 작동하는 모든 도구를 사용할 수 있다는 것입니다
이 장(및 책!)을 마무리하기 전에 이러한 모든 기술을 테스트 주도 개발 (즉, 실패한 테스트를 먼저 작성한 다음 제대로 구현하여 새로운 기능을 추가하는 것)에 사용할 수 있음을 보여드리고 싶습니다. ).
빨강-녹색-리팩터링
'책 스터디 > [완료] FP - Grokking Funtional Programming' 카테고리의 다른 글
Grokking Functional Programming - 2부 11장 (0) | 2023.02.01 |
---|---|
Grokking Functional Programming - 2부 10장 (0) | 2023.01.26 |
Grokking Functional Programming - 2부 9장 (0) | 2023.01.19 |
Grokking Functional Programming - 2부 8장 (0) | 2023.01.11 |
Grokking Functional Programming - 2부 7장 (0) | 2023.01.04 |