생각을 개발하자, 박진형

TIL - 0611

인수테스트는 클라이언트 입장

  • 인수테스트를 할 때 서버의 자원을 끌어다 사용하면 안됨 : 클라이언트 입장에서 테스트를 하는 것인데, 클라이언트는 알 필요가 없음
    • 클라이언트 - 서버가 나뉘어져있는데, 클라이언트가 서버 입장에서 서버의 자원을 사용하는 것과 같음
    • 서버가 외부로 공개해놓은 API를 콜 했을 때 어떤 결과가 받아질 것인지 예상한다음 응답 결과가 왔을 때 실제 그런지를 테스트하면 됨
  • end to end 테스트인 점을 망각한 코드
    • 첫번째 예시 : 서버에서 예외를 캐치한 후 예외에 대한 특정 응답을 만들어서 클라이언트에 응답해줘야하는데, 클라이언트 측에서 예외를 만나기때문에 다음과 같이 테스트 코드가 잘못 만들어진 것 - 구체적으로 어떤 예외인지 알 필요가 없음
    • 두번째 예시 : 클라이언트는 서버가 어떤 자원을 사용하는지 알 필요가 없음, 오로지 공개된 API로 콜하고 그에 대한 응답을 테스트하면 되는 것인데, 해당 예시는 클라이언트가 직접 서버의 자원에 접근해서 핸들링한 후 그에대한 테스트를 진행하겠다는 것
/*************** [1] ***************/
@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
public class UserAcceptanceTest {

    @Test (expected = EntityNotFoundException) 
    public void get_test() {
    
    }
}

/*************** [2] ***************/
@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
public class UserAcceptanceTest {

    @Autowired
    private UserRepository userRepo;

}

트랜잭션 알아보기(1)

  • 트랜잭션이란?
    • 사전 정의로는 거래, 이해하기로는 상호작용으로 생각했음
    • 여기서 거래는 DBMS와 DBMS를 사용하는 클라이언트 간의 거래 : 데이터 추가/읽기/수정/삭제 거래 행위가 있음
  • 트랜잭션은 단위를 뜻하기도 함
    • 어떤 단위냐면 거래의 단위 : 하나일 수도 있고, 개발에 따라 여러개의 트랜잭션이 하나로 뭉쳐 하나의 트랜잭션으로 처리될 떄도 있음
  • 트랜잭션을 처리할 떄 반드시 지켜야할 4가지
    1. 원자성 : 하나 혹은 하나로 뭉쳐진 트랜잭션은 절대 쪼개어서 처리하면 안됨 - 올바르지않은 결과가 나타남, 가장 흔한 예인 송금 과정(트랜잭션)을 살펴보자면 A의 통장에서 B통장으로 송금을 한다면 우선 A의 통장 잔고는 송금한 금액만큼 마이너스가 됨, B 통장으로 입금 과정에서 에러가 발생했고, 트랜잭션이 종료된다면 A의 통장 잔고만 마이너스될 것, 문제점을 없애기위해 하나로 묶인 트랜잭션은 모두 성공적으로 처리되었을 때 커밋(완료)을 하고, 중간에 실패가 된다면 트랜잭션 시작 전 상태로 돌아가기(roll back)를 하게 트랜잭션 처리를 해야함
    2. 격리성 : 동시에 처리되는 트랜잭션 간에 간섭하면 안됨 - 다른 트랜잭션의 부분적인 상태값을 얻어서 안됨, 얻을 수 있게 하면 안됨
    3. 지속성 : 트랜잭션이 성공적으로 완료되면 데이터베이스에 동기화를 해서 트랜잭션 처리 결과가 영구적으로 적용되도록 해야함
    4. 일관성 : 트랜잭션 처리 과정에서 나온 결과를 가지고 트랜잭션 처리를 진행하는게 아니라 트랜잭션 시작 전 상태를 가지고 처리를 진행해야함
  • 앞으로 공부할 것 : 트랜잭션 in 스프링
    • @Transactional : 선언적 트랜잭션 처리, 스프링에서 트랜잭션을 구현할 때 코드로 직접 구현하지않고도 트랜잭션을 구현할 수 있도록 스프링에서 추상화시킴

REST API - HATEOAS 지키기