본문 바로가기
반응형

테스트코드26

1. 좋은 함수 만들기 - 부작용과 거리두기 요즘의 개발에서 프레임워크나 라이브러리 사용이 없는 개발은 생각하기 어렵다. 특히 DDD 등의 개념까지 기본지식처럼 취급되어 점점 추상화된 개발에 익숙해지고 있다. 복잡한 애플리케이션 구현을 하다보면 이러한 것들에 대해 당연히 필요하다. 다만, 이게 심해지다보면 실제 구현을 해야할 변수, 함수, 클래스 등을 잘 작성하는 것보다 프레임워크나 라이브러리의 기능을 얼마나 많이 알고 있느냐를 개발자의 성장으로 오해할 수도 있다. 프레임워크와 라이브버리와 같은 도구에 대해서 숙련도가 높다면 당연히 좋겠지만, 그 이전에 좋은 변수, 함수, 클래스에 대해 먼저 고민하는 것도 필요하다. 그래서 이번 시리즈에서는 좋은 함수에 대해서 이야기하려고 한다. JS/TS 환경에서 불변객체 다루는 방법이 순수 함수형 언어들에 비해.. 2023. 1. 18.
NodeJS에서 데이터베이스 통합 테스트 성능 개선하기 (TypeORM, Jest, PostgreSQL) 보통 통합 테스트는 SQLite, H2와 같은 InMemory 데이터베이스를 사용한다. 메모리상에만 존재하기 때문에 실제 ORM (SQL) 을 검증이 가능하면서도 병렬로 테스트를 수행할 수 있고, 고속의 쿼리 수행이 가능하기 때문이다. 대부분의 데이터베이스 쿼리는 InMemory 데이터베이스에 대해 실행할 수 있지만 많은 엔터프라이즈 시스템은 실제 Production과 같은 데이터베이스에 대해서만 테스트할 수 있는 복잡한 쿼리를 사용한다. 그래서 운영 환경에서 사용하는 데이터베이스(MySQL, PostgreSQL 등) 에서 지원하는 여러 기능(Windows함수, 프로시저, 트리거 등) 들을 적극적으로 사용하는 환경에서는 InMemory DB로 검증하는데 한계가 있다. 이를 위해 보통은 로컬 PC에서는 D.. 2022. 12. 25.
5. 테스트하기 좋은 코드 - SQL 지난 시간까지 애플리케이션 코드를 어떻게 개선하면 좋을지에 대해 이야기를 나눴다. 1. 테스트하기 어려운 코드 2. 제어할 수 없는 코드 개선 3. 외부에 의존하는 코드 개선 4. 검증이 필요한 비공개 함수 개선 이번 편에서는 애플리케이션 코드가 아닌 Query (비단 RDBMS뿐만 아니라 NoSQL도 해당) 에 대해서 이야기를 해본다. 최근엔 ORM (혹은 ODM) 사용이 대중화되었지만, 여전히 많은 프로젝트에서는 SQL Builder를 통해서 Native Query를 작성한다. SQL Builder를 통해서 Native Query를 작성하는 것은 복잡한 조회 조건이 필요한 환경에서는 굉장히 효율적인 방법이다. 예를 들어, 통계/정산/물류 등 복잡한 조회 Query가 필요하거나, Bulk Insert등.. 2022. 10. 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.
2. 테스트하기 좋은 코드 - 제어할 수 없는 코드 개선 1편 을 통해 테스트하기 어려운 코드에 대해 이야기를 나눴다. 이번 편에서는 테스트하기 어려운 코드 중 첫번째인 "제어할 수 없는 코드를 개선하는 법"을 이야기해보자. 2-1. 문제 상황 먼저 앞에서 보았던 discount() 코드를 다시 보자. export default class Order { ... discount() { const now = LocalDateTime.now(); if (now.dayOfWeek() == DayOfWeek.SUNDAY) { this._amount = this._amount * 0.9 } } } 이 discount() 는 실행할때마다 항상 결과가 다르다. LocalDateTimw.now()의 코드를 보면 알겠지만, 현재 시간은 항상 다르기 때문이다. 그렇기 때문에 실행.. 2022. 9. 1.

728x90
반응형