Today I Learned 날짜 2024년 8월 16일 금요일 내용 테스트케이스 추가 무려 6개월 전에 진행했던 리스트 디자이너의 테스트 케이스를 추가해줬다. 허허.. 진작에 좀 부지런하게 해놓을껄.. 깃헙 액션으로 풀리퀘스트를 머지할 때마다 테스트를 진행해 결과를 나타내고, 커버리지로 테스트되는 코드 비율을 표시하려고 했는데 약간의 문제가 있다. 결국 빌드해서 파이테스트를 돌려봐야 하는데, 깃헙에선 환경변수 파일이 없으니 실행 과정에서 자꾸 오류가 난다. 그렇다고 필요한 환경변수를 모두 repostiory 환경 변수로 설정할 수도 없고 흠.. 다른 방법이 뭐가 있을까 고민하다가 ...
Today I Learned 날짜 2024년 8월 12일 월요일 내용 테스트코드 정상화 유지보수 중 생각보다 시간 여유가 생겨 테스트코드를 작성했다. 가장 자주 문제가 되는 부분인 서비스 활성화 부분에 대한 코드다. 특정 앱을 사용 시작했을 때 shop_detail이 제대로 바뀌는지 확인하는 코드다. mock_s3_resource랑 mock_send_email_for_starting_user 는 쓰이지 않는데, 뺴면 아예 오류가 뜬다. 원인이 뭐꼬… 처음에 제대로 작동이 안됐는데 이전 테스트에서 생성된 shop이 데이터베이스에 남아있어서 문제가 됐다. 각 유닛테스트가 끝나면 꼭 데이터베이스를 초기화 하는게 중요하다. ...
Today I Learned 날짜 2024년 5월 24일 금요일 내용 테스트 코드 작성을 위한 DB 모델링 우리 서비스의 테스트 코드는 pytest로 작성되어 있고, 데이터베이스는 SQLite다. SQLite는 파일 형식이라 만들고 뚝딱 삭제해버리면 금방이다. 우리 데이터베이스인 Postgres 와 마찬가지로 SQL이긴 하나 약간의 기능 차이는 존재한다. 하나 꼽자면 jsonb 타입의 필드가 없다. jsonb는 json과 달리 내부의 키로 검색할 수 있는 나름 유용한 타입이다. 쇼피파이에서 넘어오는 스토어 데이터는 Shop 테이블에 담긴다. 가공없이 그대로. 스토어와 관련해서 우리가 필요하고 자주쓰는 데이터는 이 자식테이블 격인 shop_detail에 담긴다. 여기에 apps_log라는 이름으로, 그 스토어가 활성화한 서비스가 어떤 것인지를 담는데 이 필드가 jsonb 타입이다. ...
Today I learned 날짜 2023년 11월 27일 월요일 내용 테스트 코드를 고쳤다. 근데 제대로 된 건지 모르겠다.. 반복 실행해서 일관성도 확인해보고, 원하는 검증이 이뤄진건지 로직도 다 확인해봐야 한다. 테스트 함수 1 TypeError 메시지로 보아 어떤 변수가 특정 함수 의 parameter로 없는 것으로 예상된다. 실제로 저 메서드를 찾아가보니 없길래 테스트 코드에서도 삭제해주었다. parameter로 들어간 값을 schemas 파일에서 Type 클래스를 가져와 그중 1개를 선택하도록 변경하였다. 메서드 내의 다른 함수의 반환 타입이 예상과 다르다는 오류가 발생했다. ...
Today I Learned 날짜 2023년 11월 24일 금요일 내용 테스트 코드 실행과 관련해서 Docker 내에서 실행해보라는 조언이 있어서 실행했다. 약간의 에러만 해결한 이후, 빠르게 테스트 코드 작성에 들어갈 수 있었다. Docker 내 실행 환경변수 건드리지말고 docker-compose exec 로 도커내에서 실행해보라는 태용님의 조언이 있었다. docker-compose exec service이름 실행내용 -v 을 통해 review 컨테이너 내에서 pytest를 진행했다. 하지만 오류로 테스트가 진행되지 않았다. 오류는 안뜨고 5성공, 5실패가 뜬다. 테스트 코드 작성 test_setup reviews_id 가 NOT NULL 인데 안들어가는 걸로 파악했다. Factory로 만들어진 review들의 id값을 확인할 수 있도록 코드를 수정했더니 모두 null값이 들어가 있었다. Factory 파일에선, Product는 id값을 1씩 증가하도록 배정해준반면 review에는 그러한 코드가 없었다. 둘다 모델 설정에는 BigInteger 이자 primary_key, index, unique로 지정되어있다. primary key가 True라면 자동으로 배정되야 하는지 나중에 찾아보자! 일단 factory처럼 증가하는 숫자를 넣었다. ⇒ 통과! test_get_widget 테스트 함수에서 parameter로 없는 것이 작성되어 있었다. 실제로 저 메서드를 찾아가보니 없길래 테스트 코드에서도 삭제해주었다. type으로 들어간 값은 schemas 파일에서 클래스를 가져와 그중 1개를 선택하도록 변경하였다. 기능 함수 내의 또다른 기능 함수의 반환이 예상과 다르다는 오류가 발생했다. 여기서 내가 기능 함수를 함부로 수정하면 안될것 같아 리더님께 여쭤봤는데, 현재 잘 작동되고 있는 메서드이고, 중요한 기능이라 시간을 들여 테스트 코드를 제대로 작성하는 쪽으로 진행하는게 좋다고 말씀해주셨다. 역시 “해도되나?” 는 안하는게 맞다. 테스트 코드 내 함수에서 param을 수정하였다. 기능 함수의 일부 params는 Query[None] 타입이다. 이는 값이 존재할 땐 Query로 처리하지만 없을땐 None으로 처리하겠다는 의미로 FastAPI에서만 쓰인다. 이 값이 데이터베이스 쿼리에 포함되면서 오류가 발생함. 실제 배포 서비스에서는 해당 값들이 어떤 이유로든 반드시 입력되어서 오류가 발생하지 않은 걸까? 일부 param들에 구체적인 값을 넣어줬더니 PASS 처리 되었다. 하지만 확실한 테스트를 위해 내 가설을 검증할 필요가 있다. 검증 사항 : 위 값들은 항상 주어질 수 밖에 없는 값인가? 모든 종류의 입력에서 무조건 설정하게 되있는 경우 입력이 없을때 넣을 값에 대한 로직이 존재하는 경우 기본값 있는 경우 따라서 이 값들은 입력값이 반드시 존재한다. schemas 상 범위 내의 값을 무작위로 넣어주면 될듯 ⇒ 통과 회고 이번에는 테스트 해야 할 함수들이 정상적으로 작동하고 있다는 확신이 있기 때문에 테스트 코드만 집중적으로 공략할 수 있었다. 만약 내가 방금 만들어낸 코드의 테스트가 실패했을 때, 내 테스트 코드를 신뢰할 수 없다면 오히려 코드의 정확성을 망치게 될 것 같다. 확실하게 무엇을 테스트 해야하는지, 공부했던 규칙들을 지키면서 신뢰성 있는 테스트 코드를 공부하자. ...