단위 테스트10 2. 좋은 함수 만들기 - 암묵적 입력/출력 지난 시간에 부작용 (부수효과) 함수에서 어떻게 최대한 부작용과 거리두기를 해서 좋은 함수를 만드는지 간단한 예제로 연습해봤다. 이번 시간에는 좋은 함수가 되기 위해 관리해야할 부작용이란 어떤 것들이 있는지 알아보자. 1. 암묵적 입력/출력 좋은 함수는 "부작용 (부수효과) 이 없으며, 멱등성을 유지할 수 있는 함수" 라고 했다. 이 부작용 (부수효과) 함수에는 크게 2가지 특징이 있다. 암묵적 입력 (implicit input) 암묵적 출력 (implicit output) 1-1. 암묵적 입력 (implicit input) 암묵적 입력이란 함수의 입력값으로 명시적으로 전달되지 않는 파라미터를 의미한다. 예를 들자면 다음과 같은 경우 암묵적 입력이다. 함수의 인자는 없는데 함수 내부에서 쿠키에서 값을 가.. 2023. 3. 1. 1. 좋은 함수 만들기 - 부작용과 거리두기 요즘의 개발에서 프레임워크나 라이브러리 사용이 없는 개발은 생각하기 어렵다. 특히 DDD 등의 개념까지 기본지식처럼 취급되어 점점 추상화된 개발에 익숙해지고 있다. 복잡한 애플리케이션 구현을 하다보면 이러한 것들에 대해 당연히 필요하다. 다만, 이게 심해지다보면 실제 구현을 해야할 변수, 함수, 클래스 등을 잘 작성하는 것보다 프레임워크나 라이브러리의 기능을 얼마나 많이 알고 있느냐를 개발자의 성장으로 오해할 수도 있다. 프레임워크와 라이브버리와 같은 도구에 대해서 숙련도가 높다면 당연히 좋겠지만, 그 이전에 좋은 변수, 함수, 클래스에 대해 먼저 고민하는 것도 필요하다. 그래서 이번 시리즈에서는 좋은 함수에 대해서 이야기하려고 한다. JS/TS 환경에서 불변객체 다루는 방법이 순수 함수형 언어들에 비해.. 2023. 1. 18. 4. 테스트하기 좋은 코드 - 검증이 필요한 비공개 함수 지난 시간까지 테스트하기 어려운 코드를 어떻게 개선하면 좋을지에 대해 이야기를 나눴다. 1. 테스트하기 어려운 코드 2. 제어할 수 없는 코드 개선 3. 외부에 의존하는 코드 개선 지금까지 글들의 결론은 간단하다. 테스트 하기 어려운 코드와 테스트 하기 쉬운 코드를 분리하되, 테스트 하기 어려운 코드는 최대한 바깥으로 몰아넣는다. 전체적인 방향성은 위와 같이 유지하되, 이번에는 조금 더 세밀한 내용을 보자. 비즈니스 로직을 작성하다보면 무수히 많은 private 메소드/함수들을 생성하게 된다. 이전 글에서도 언급했지만, private 메소드/함수의 테스트 코드는 작성하지 않는 것이 좋을때가 많다. 테스트 코드에서 내부 구현 검증 피하기 그럼에도 불구하고 private 메소드/함수를 검증해야할 경우가 있다.. 2022. 10. 2. 3. 테스트하기 좋은 코드 - 외부에 의존하는 코드 개선 지난 시간에 테스트하기 좋은 코드에 대해 이야기를 나눴다. 1. 테스트하기 어려운 코드 2. 제어할 수 없는 코드 개선 이번 편에서는 테스트하기 어려운 코드를 개선하는 2번째 방법인 외부에 의존하는 코드를 개선하는 방법에 대해 이야기를 해보자. 3-1. 문제 상황 1부 에서 소개했던 cancel() 코드를 다시 보자. export default class Order { ... async cancel(cancelTime): void { if(this._orderDateTime >= cancelTime) { throw new Error('주문 시간이 주문 취소 시간보다 늦을 수 없습니다.'); } const cancelOrder = new Order(); cancelOrder._amount = this._a.. 2022. 9. 27. Stub 을 이용한 Service 계층 단위 테스트 하기 간혹 Service 계층을 항상 통합 테스트로만 작성하는 경우를 보게됩니다. 모든 Service를 통합 테스트 혹은 E2E 테스트로만 검증하기 보다는 상황에 따라 적절한 Stub을 사용하여 단위 테스트로 작성한다면 전체 테스트 속도 향상에 도움이 됩니다. 몇가지 예제를 통해 Stub을 사용하는 단위 테스트 코드를 보겠습니다. 모든 코드는 Github 에 있습니다.. 예제 1. 첫번째 예제로 다음과 같은 서비스 로직에 대한 단위 테스트입니다. export class OrderService { constructor(private readonly orderRepository: OrderRepository) { } validateCompletedOrder(orderId: number): void { const .. 2022. 2. 12. 검증부 (assert / expect)는 하드코딩한다 최근 코드리뷰를 하다가 자주 지적하던 내용이 있어, 정리하게 되었다. 요즘 팀 분들이 가장 많이 하는 실수가 바로 검증부에 도메인 로직이 추가되는 것이다. 이를테면 다음과 같은 구현 클래스가 있다고 해보자. export class FilePath { private readonly _path1: string; private readonly _path2: string; private readonly _path3: string; private readonly _path4: string; constructor(path1: string, path2: string, path3: string, path4: string) { this._path1 = path1; this._path2 = path2; this._path.. 2021. 11. 15. 이전 1 2 다음
