chap 2
👩🏫 일반 개발 방식과 TDD 개발 방식의 차이는?
🙋♀️ 일반 개발 방식은 설계 -> 개발 -> 테스트
TDD 개발 방식은 설계 -> 테스트 코드 -> (리팩토링 ->) 개발 -> 리팩토링
chap 3
👩🏫 예외 상황은 코드를 뒤집거나 조건문을 중복해서 추가해야 하는 일이 벌어지기 때문에, 코드를 모두 작성한 뒤 모든 예외 상황을 고려하여 추후에 적용한다.
🙋♀️ X
코드를 모두 작성하기 전이 아니라 초반에 예외 상황을 테스트 하여 코드의 복잡성을 줄이고 버그 발생 가능성을 낮춰야 한다. 예외 상황에 따른 if-else 구조가 미리 만들어지기 때문에 많은 코드를 완성한 뒤에 예외 상황을 반영할 때보다 코드의 구조가 덜 바뀐다.
chap 4
리턴 값, 익셉션, 변경
👩🏫 위 보기 중 빈칸에 알맞은 것은?
회원 가입 기능을 테스트 할 때, 회원 가입에 성공하면 DB에 회원 정보가 저장된다. 이는 테스트의 결과 형식 중 __ 에 해당한다. 하지만 동일 ID가 존재할 경우 테스트 결과 형식은 __ 이 된다.
🙋♀️ 변경, 익셉션
결과는 상황에 따라 달라질 수 있다. 가장 쉽게 생각할 수 있는 결과 형식은 리턴 값이고, 익셉션을 사용하여 테스트 실패를 나타낼 수 있으며, 결과로 시스템의 상태를 변경할 수도 있다.
chap 5
👩🏫 1. @Test 애노테이션을 붙인 메서드는 private이면 안 된다.
🙋♀️ O
추가적으로, @BeforeEach 애노테이션과 @AfterEach 애노테이션을 붙인 메서드도 마찬가지로 private이면 안 된다.
👩🏫 2. 각 테스트 메서드는 서로 ____ 으로 동작해야 한다.
🙋♀️ 독립적
각 테스트 메서드는 서로 독립적으로 동작해야 한다. 한 테스트 메서드의 결과에 따라 다른 테스트 메서드의 실행 결과가 달라지면 안 된다. 그런 의미에서 테스트 메서드가 서로 필드를 공유한다거나 실행 순서를 가정하고 테스트를 작성하지 말아야 한다.
chap 6
👩🏫 테스트 코드의 구성 요소는 __ , __ , __ 이다.
🙋♀️ 상황, 실행, 결과 확인
테스트 코드는 기능을 실행하고 그 결과를 확인하므로 상황, 실행, 결과 확인의 세 가지 요소로 테스트를 구성할 수 있다. 어떤 상황이 주어지고, 그 상황에서 기능을 실행하고, 실행한 결과를 확인하는 세 가지가 테스트 코드의 기본 골격을 이루게 된다. 하지만 이 구조는 테스트 코드를 작성하는데 도움을 줄 뿐 너무 집착할 필요는 없다.
chap 7
👩🏫 대역의 종류에는 __, __, __, __ 가 있다. 이 중 실제 동작하는 구현은 필요하지 않고 단순히 원하는 동작만 수행하면 되는 대역은 ___ 이다.
🙋♀️ 스텁, 가짜, 스파이, 모의 / 스텁
chap 8
👩🏫 LocalDate.now() 혹은 Random와 같은 코드에 의해 같은 테스트 코드라도 실행하는 시점에 따라 테스트 결과가 달라진다면 이를 어떻게 해결할 수 있을까?
🙋♀️ 테스트를 하고자 하는 기능 일부만 별도 기능으로 분리해서 테스트를 진행한다. 또는 테스트하고자 하는 기능 자체를 대역으로 변경하여 '의존 대상 주입'을 한다.
이외의 코드가 올바르게 동작해야 테스트를 하고자 하는 주요 기능의 테스트가 가능하므로 대역 또는 실제 구현 등이 필요하다.
chap 9
👩🏫 테스트는 DB 연결, 소켓 통신, 스프링 컨테이너 초기화 같이 테스트 실행 속도를 느리게 만드는 요인이 많다. 테스트는 브라우저나 앱을 구동하고 화면의 흐름에 따라 알맞은 상호작용을 해야 한다.
🙋♀️ 통합, 기능
👩🏫 아래 테스트 범위 설명이 맞으면 O, 틀리면 X
(느림) E2E 테스트 <-> 통합 테스트 <-> 단위 테스트 (빠름)
🙋♀️ O
