프로젝트 4주차 (트랜잭션, 테스트코드고민)

이번주는 메뉴를 만드는 작업을했습니다.
음 가장 고민했던것은 우선순위변경로직이였습니다.

배민에서 화면을 볼때 메뉴 그룹과 메뉴들이 우선순위가 존재합니다.

예를들어 세트메뉴, 단품, 사이드 메뉴와 같이 메뉴그룹이 존재하는데 이 우선순위를 변경할때 작업을 진행했습니다.

 

첫번째로 우선순위를 변경할때 하나만 변경되면 나머지도 함께 변경하고자했습니다. 그래서 자료구조를 통해 순서대로 넣어서 변경할려고했습니다.

그런데 이 로직에는 문제점이 많았습니다. 바로 하나만변경되는데 나머지들도 바꿔줘야하기때문에 뒤로밀려난다면 하나하나 꺼내서 바꿔주는것도 생각해야하고 로직상으로 많이 복잡했습니다.

 

그래서 만약 프론트가 데이터를 화면에보이는대로 위에서 아래로 우선순위를 받는다면 한꺼번에 업데이트를 하고자 하는걸로 변경했습니다. 

처음에는 Mybatis의 Batch Update를 이용하지않았습니다. 그래서 for문을 통해서 업데이트를 시킬려고했습니다. 그런데 이러한 로직의 문제점이있습니다. 바로 매번변경시켜줄때마다 DB접근을 해야한다는것입니다. 그러면 매번 하나 업데이트마다 DB와 연결하는 과정도 반복됩니다. 그래서 DB접근을 한번이지만 Batch로 Mybatis에서 update시킨다면 DB접근을 줄일수 있다고 생각했습니다.

 

차이나는 이유는

배치처리안하면 MyBatis가 실행되는 과정, 쿼리 실행 모두의 과정이 만번이 발생하게 되는 것입니다. 

 MyBatis 인터페이스 메소드 호출 -> Mapper id 검색 과정이 1번만 실행되고 쿼리단에서만 만번이 실행되는 것입니다.

그런데 또한 문제점이있습니다.

트랜잭션이 보장이안된다는것입니다. update작업을 for문으로한다면 하나라도 실패하면 롤백되지만 이작업은 롤백이 없었습니다. 왜냐하면 update시에 존재하지않는 id가있을경우 실행시키고 오류가 발생되지않기때문입니다. 그래서 저는 최대한 트랜잭션이 비슷하게 보장되기위해서 1차적으로는 처음들어온 개수와 DB존재하는 개수의 수를 검사를 통해 누락되지않고 업데이트 되게 실행시켰습니다. 

 

매번 테스트케이스를 작성하면서 느낀것입니다.

통합테스트할 경우 저는 Valid체크가있기때문에 dto로 들어오는 값들의 valid예외가 발생되는 상황도 체크했습니다.

그런데 문제점이 저희는 Post, Update 시에 사용하는 dto가 동일합니다. 

그래서 테스트케이스작성할떄 post요청때 작성했던 부분을 update시에 valid하는부분을 HTTP 메소드만 다르고 요청이 같다고 생각하여 제가 살충제페러독스처럼 동일한케이스를 반복한다고 느꼈습니다. 이러한 경우도 체크를 해야하나 의문점이 들어 저는 작성을 안했습니다. 그러나 테스트케이스는 많을수록 더 좋다고생각하지만 동일한 케이스는 반복되는게 필요하나 느끼며 갈등을했습니다. 결국은 작성을 안했지만 이 경우에 대해서는 알아봐야할것같습니다.

 

이번한주도 열심히 했습니다.

단순하지만 많이 고민하면서 느끼는것들이 많았습니다. 제가 성장하고있는거같습니다. 과거에는 기능만 동작이 다인줄알았는데 요즘은 여러가지 경우를 생각을하기때문에 더 좋아질거라생각하고 열심히 해야겠다고생각했습니다.