티스토리 뷰
오늘 부터는, 테스트 주도 개발(켄트백)에서 예제로 쓰고 있는, Dallor 예시를 Paymt(결제)로 투영하여 테스트 코드 작성 훈련을 진행 하도록 하겠다.
1장. 결제의 종류 (카드)
요구사항
카드 수수료 (20%) 카드번호, 유효기간, 결제 금액 값 필요 card 부작용? + 수수료비율 필드 추가 + 수수료금액 필드 추가 + getChargeAmt 추가 |
CardTest
@Test
void CardChargeTest() {
Card card = new Card(0.2);
card.getChargeAmt(1000);
assertEquals(card.chargeAmt, 200);
}
테스트 코드 부터 작성 하고... 초록 막대기가 보이게(테스트 성공) 하게 바꾸자.
Card
package com.example.demo;
public class Card {
private double chargeRate = 0;
private final int payAmt = 0;
Card(double chargeRate) {
this.chargeRate = chargeRate;
}
public int getChargeAmt(int amt) {
return amt *= chargeRate;
}
}
초록 막대 보기 성공~!
느낌점 : 일부로 테스트 주도 개발을 위해, 캡슐화, 객체화를 안하는 감이 있지만 2장에서 부터 차차 해당 내용을 수정하며 TDD 를 연습 할 것 같다!
2장. 타락한 카드 (?)
우선 1장에서 완료한 요구 사항은 자랑스럽게 취소선으로 없애주자
요구사항
카드번호, 유효기간, 결제 금액 값 필요 card 부작용? |
여기서 나는 아래와 같이 Card 의 수수료 값이 변경되도록 테스트를 구성하고 싶다.
CardTest
@Test
void CardChargeTest() {
Card card = new Card(0.2);
card.getChargeAmt(1000);
assertEquals(card.chargeAmt, 200);
card.getChargeAmt(1000);
assertEquals(card.chargeAmt, 300);
}
나는 테스트시 여러 수수료를 부가하여, 카드가 수수료가 잘 적용되는지 보고 싶다. 하지만 위와 같이 코드를 작성하면 기존 생성 값을 계속 따라 가기 때문에 테스트는 당연하게 Fail~! 어서 초록 막대로 만들자~!
CardTest
@Test
void CardChargeTest() {
Card card = new Card(0.2);
Card hanCard = new Card(0.3);
card.getChargeAmt(1000);
assertEquals(card.chargeAmt, 200);
hanCard.getChargeAmt(1000);
assertEquals(hanCard.chargeAmt, 300);
}
요구사항 자랑스럽게 지우기!
카드번호, 유효기간, 결제 금액 값 필요 |
느낀점 :
원래 책에서는 설계상의 부작용(결함)을 알리기 위해 함수 times(곱샘) 함수가 new 객체를 하게 만들었는데, 함수에서 생성해서 전달 하는게 너무 이상한거 같아서... 이번 예제는 내가 만든 Card 객체는 생각보다 타락(설계가 잘못됨)하지 않았다는 교훈을 남기고 넘어 가겠다.
3장. 모두를 위한 평등
우리는 이장에서 별칭의 문제 (Call by Reference) 로 인해 HanCard 에 수수료 값을 변경 하였을때, Card 에 대한 수수료 까지 변경할 수 있는 케이스에 대해서 요구사항에 넣고 해결해 보도록 하자. (책에서는 수표로 비교했다)
요구사항
카드번호, 유효기간, 결제 금액 값 필요 hashCode() |
equals 관련 테스트 코드를 작성해 보자
CardTest
@Test
void equalsTest() {
assertTrue(new Card(0.2).equals(new Card(0.2)));
}
우선 equals 테스트 코드를 작성하고 우리는 초록막대를 봐야 하니까 equals 를 구현한다.
public boolean equals(Object object) {
return true;
}
초록막대 획득~!
여기서 우리는 너무 긍정적 테스트 코드만 짠것 같다. 실패케이스에 대해서도 테스트를 추가하자~!
CardTest
@Test
void equalsTest() {
assertTrue(new Card(0.2).equals(new Card(0.2)));
assertFalse(new Card(0.2).equals(new Card(0.3)));
}
위의 테스트는 당연히 실패한다~! 우리의 equals 함수는 항상 true 만 리턴하는 yes 맨 이니까..
이제 우리는 yes 맨이 진짜 일을 할 수 있게 만들어 보자.
public boolean equals(Object object) {
Card card = (Card) object;
if (this.chargeAmt != card.chargeAmt) {
return false;
}
if (this.chargeRate != card.chargeRate) {
return false;
}
return true;
}
다시 테스트를 돌려보자~!
성공~!
항상 우리의 업적은 취소선을 통하여 자랑하자~!
요구사항
카드번호, 유효기간, 결제 금액 값 필요 equals() hashCode() |
느낀점 :
우리의 디자인 패던(값 객체)이 하나의 또 다른 오퍼레이션을 암시한다는 걸 알아챘으며, 해당 오퍼레이션을 테스트 했다~!
다음, 4장은 프라이버시 인데... 습관적으로(?) 클레스 선언시에 private 로 변수접근을 제한했기 때문에... 4장에서는 지금 우리 변수가 잘 private 한지 테스트를 해보도록 하자~!
참고 : 테스트 주도 개발 (켄트 백)
'테스트' 카테고리의 다른 글
테스트 주도 개발_4 (0) | 2023.02.12 |
---|---|
테스트 주도개발_3 (0) | 2023.02.12 |
테스트 주도 개발_1 (0) | 2023.02.05 |
TDD 훈련을 위한 주제 정하기 (0) | 2023.02.05 |
BDD (0) | 2019.02.26 |
- Total
- Today
- Yesterday
- kafka
- MSA
- EC2
- 분산처리
- Python #FastAPI
- 테스트주도개발
- 퀜트백
- nodejs
- 테스트 주도 개발
- MQ
- Python
- data crawling
- mongodb
- 웹개발
- TDD
- AWS
- GateWayApi
- 테스트
- 켄트 백
- fastapi
- SpringBoot
- 웹서비스
- data mining
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |