![]()
이제 테스트코드의 필요성은 굳이 여기서 말을 하지 않아도 될 정도로 다들 잘 알고있고 그만큼 널리알려져 있다고 생각한다. 그래도 개인적인 경험을 말해보자면 난 처음부터 테스트코드를 작성하진 않았 다. 사실 그땐 테스트코드에 대한 존재 자체도 잘 몰랐다. 첫 회사에선 코드를 작성하고 서비스를 운영 했던 방식은 다음과 같았다. (프론트, 백엔드 모두 작업하던 환경) 1. 신나게 어플리케이션 코드 작업 2. 손수 한땀한땀 클릭 클릭, 오고가는 데이터까지 확인하며 기능 작동 확인 3. 버그 발견시 1. 로 회귀. Or 스테이지 서버에 배포후 다시 한번 기능 테스트 (QA) 4. 배포 이렇게 일을 하며 느꼈던 점은 테스트 과정이 지루하기도 하고 기존 기능에 무언가 추가 되었을때 똑같은 테스트를 또 해야했기에 ..
Laravel Test 에 관하여.. 보통 in-memory (sqlite) 디비와 같이 사용하길 권장하는것 같다. RDBMS 에 비해 상대적으로 속도면에서도 빠르고 초기 데이터베이스 셋팅을 할 필요가 없으니 편할수 있다. 근데 개인적으론 테스트디비로 sqlite을 사용했을때 이슈가 좀 있었다. 내가 경험했던 이슈는 전체 스키마에 걸쳐 인덱스명이 유니크 하지 않아 인덱스명 duplicate 오류가 발생했었다. 그리고 sqlite 에서 index명 length limit 관련해서도 에러가 났었던거 같은데 기억이 가물가물 하다 그리고 현재 재직중인 회사에서도 sqlite 를 쓰지 않고 운영 환경과 같은 mysql 을 테스트디비로 사용하고 있다. 왜냐하면 좌표(geo) 컬럼은 sqlite 에서 지원해주지 않는..
