# test case

ninthsun91

TDD는 실제 코딩하는 시간보다 이를 먼저 설계하고 준비하는 단계에 투자하는 시간이 더 많아야한다는 말이 있다. 그만큼 내가 지금 만들려고하는 것이 무엇인지 그 목적을 명확히하고 어떻게 테스트할 것인지 구체적인 케이스들을 정리하는 것이 중요한 작업이다. 여기서는 배달서비스에서 회원가입이라는 기능을 가볍게 구현하기 위해 앞선 장에서 살펴본 방법론에 따라 테스트 케이스들을 만들어보기로 한다. 1. 요구사항 먼저, 회원가입에 대해 다음의 두 가지 요구사항이 있다. 사용자 회원가입이 필요하다 매장 사장님 회원가입이 필요하다 2. 테스트 시나리오 두 가지 종류의 회원 가입이 있기 때문에 일반 사용자가 접근하는 회원가입 페이지와, 매장 사장님이 접근하는 회원 가입 페이지가 다를 것이다. 또, 보통 매장사장님 같은 유형의 기업/사업자 회원은 회원가입시 사업자등록증 검사 등의 작업이 함께 이루어지는데, 이번 프로젝트에서는 한명의 사업자가 여러 매장을 운영할 수 있

damianos

구독 기반의 사용자 시나리오 계정 및 인증: 회원 가입 및 로그인 비밀번호 찾기/재설정 소셜 미디어 계정 연동 이메일 인증 및 변경 회원 탈퇴 구독 관리: 구독 상품 선택 및 가입 구독 변경 구독 취소 결제 수단 추가/변경/삭제 결제 이력 조회 상품 및 카테고리 관리: 상품 검색 카테고리별 상품 조회 상품 상세 정보 조회 상품 리뷰 작성 및 조회 관련 상품 추천 쿠폰 및 로열티: 쿠폰 코드 발급 및 입력 쿠폰 사용 시 할인 적용 쿠폰 사용 조건 및 만료일 확인 로열티 포인트 적립 및 사용 로열티 포인트 조회 및 히스토리 주문 및 배송: 장바구니 관리 (상품 추가/수정/삭제) 주문 확인 및 결제 주문 취소 및 환불 배송지 정보 입력 및 변경

joosing

2022.08.03 깨진 오래된 테스트 케이스 간단한 CI를 구성하며 오래전에 개발한 컴포넌트의 테스트 케이스가 깨진다는 것을 알게 되었다. 왜그런지 분석해 보니 비지니스 로직 변경에 영향을 받는 다른 테스트 케이스에서 테스트 데이터를 생성하는 로직은 변경해 주지 않았기 때문이었다. 간단히 바꿔주었다. 부끄럼. 드디어 AWS 만남 그리고 오늘 처음으로 AWS S3 에 접속해 보았다. 최신 기술 스택과 거리가 멀던 나였는데 이 회사에 와서 정말 다양한 걸 경험하는 것 같아 약간 꿈같다. EC2(Elastic Compute Cloud), S3(Simple Storage Service) 약어가 궁금해서 찾아 본다. 이름 참 잘 짓는듯 하다.

joosing

낯선것을 학습하는 나 어제는 GitHub Actions 를 사용해 API 서버를 빌드하고 테스트하여 GitHub Packages에 Publish 하는 것 까지 해보았다. 기본이 없는 상태에서 샘플로 작성된 workflow 와 pom 파일만 보며 따라하다 보니 삽질을 많이 하게 된다. 그리고 결과가 나왔는데도 진짜 잘한건지 확신을 못하겠다. 내가 낯선 것을 학습하는 방식에 아쉬운 마음이 든다. 어제 나의 방식은 원하는 결과를 정하고 구글링으로 단편적인 지식을 모으며 결과가 나올 때 까지 시도해 보는 것이었다. 원하는 결과를 만나는데 오랜 시간이 걸리면 학습하고 있다는 효용감이 떨어지고 지친다.그러나 좋은 블로그를 만나 답을 의외로 빨리 찾을 때도 있다. 반대는 만든 사람이 제시하는 가이드를 따라 조금 여유를 두고 차근히 학습하는 것인데 시간이 좀 걸리고 Just Do it 을 못해보고 이론적인 학습에 매몰될 위험이 있는 것 같다. 적절히 섞어서 해봐야 겠다. 눈에 거슬리도록

redgem92

private 메서드를 테스트하고 싶어요 JUnit으로 테스트하다 보면 클래스, 메서드 또는 모듈 단위로 테스트를 진행해요. 문제는 클래스 내 메서드를 private로 캡슐화Encapsulation로 인해 내부 메서드를 테스트를 하는데 어려움이 있어요. 그렇다고 어렵사리 캡슐화된 메서드를 테스트할 때 쓴답시고 public 선언하는건 매우 비효율적이에요. 그래서 이를 테스트하기 위해 자바Java의 고유 기능인 reflection을 통해 테스트를 수행해요. 방법 클래스에 위와 같은 메서드가 있다고 가정해봐요. 이걸 JUnit 테스트 코드에선 아래와 같이 선언해서 테스트할 수 있어요. 하나씩 알아보도록 해요 ㅎㅎ. 우선 사용하려는 private 함수를 가져오기 위해 Method 변수를 선언해요. 이 때 매개변수s는 호출하려는 메서드의 매개변수에 타입에 맞춰 기입하면 되요. 이렇게 Method 인스턴스에 메서드를 담았어요. 문제는

agiletalk

간단하게 BDD를 적용해보고 기존과 다르게 개발했던 경험 원티드 앱 4.6.11의 새로운 기능 중에서 이벤트 '관심 키워드'를 설정하면, 알림으로 빠르게 이벤트 정보를 확인할 수 있는 기능을 구현하면서 간단하게 BDD를 적용해보고 기존과 다르게 개발했던 경험에 대해서 공유해보려고 합니다. (유사)라는 제목을 사용한 이유는 BDD를 적용했지만, Test Case를 먼저 작성하고 구현하고 리팩토링한 건 아니고 개발을 하기 전에 Use Case를 정리하고 Use Case 단위로 구현하고 테스트를 BDD로 했기 때문입니다. 개발 순서 기존에는 프로젝트 기획서를 보고 디자인 가이드가 나오면 UI를 우선 만들고 UI의 각 요소에 기능을 구현하고 API와 연결하는 순서로 개발을 했었는데요, 이번에는 기획서 내용을

iamjoo

isArray라는 모듈을 개발하고 test case를 작성하던 중에 발생한 문제에 대해서 정리해보겠습니다. 배열 여부를 반환해주는 간단한 함수입니다. test case를 작성시 native Array.isArray의 존재여부에 따라 크게 2가지로 나뉩니다. 위와 같이 실행을 하면 모든 test case는 Array.isArray가 존재하지 않는 경우의 코드를 타게 됩니다. 확인을 해보니 describe안에 선언된 내용은 test메서드가 실행하기 전에 실행이 되고 있습니다. native isArray 존재하지 않는 경우에 첫번째 test 메서드내에서 delete Array.isArray를 하면 위에 native isArray test case는 정상동작하며 아래 native가 존재하지 않는 경우에도 정상동작합니다. 그러나 가독성 측면에서나 떨어지는것 같아 describe구문 안에서 delete Array.isArray 하는 방법을 찾아보려고 했으나 없는