Please enable JavaScript.
Coggle requires JavaScript to display documents.
테스트 어떻게 하지? - Coggle Diagram
테스트 어떻게 하지?
MR전 단위테스트
개발 서버에 테스트 데이터를 저장해두는 방법
데이터 저장방법은?
초기 저장은 비용이 많이 들어도 괜찮다 쳐도
함수가 수정될때마다 테스트 데이터를 새로 구축해야하면
함수가 변한다. -> 아웃풋이 변한다. -> 이후 함수의 인풋이 변한다. -> 마지막까지 다 업데이트 필요?
아니면 wf에 대한 테스트가 아니라 데이터 유형별 테스트는 의미가 없을까?
미리 엣지케이스 (0행 인풋이 오는 경우, 포맷이 다른 컬럼이 오는 경우, 타입이 다른 컬럼이 오는 경우 등)의 샘플 데이터를 작은 사이즈로 만들어두고 그런 인풋이 들어왔을 때 어떤 에러가 발생하는지를 본다던가..
-> 그러면 다른 wf가 터졌을 때 왜 터졌는지 더 빨리 알 수 있을려나
이건 만약 한다면, 샘플 데이터 마련은 SI가 하고
AI에 테스트 결과지 첨부를 요구해야할듯
genbi에서는 pytest를 작성하고, MR전에 pytest 수행 후 화면 캡쳐해서 공유했던 듯
-> 엣지케이스에 대해서 전부 미리 넣어둘 수는 없겠지만, 운영에서 에러 발생시 케이스를 추가하는 방안은 가능할 듯
-> 이건 SI에서 담당
각 메소드마다 저장
단계가 많지 않으며, 중간중간 저장을 하는 경우가 많기 때문에 테스트 데이터를 저장하기는 수월한 편
하지만, 함수가 수정되었을 때 영향을 받는 메소드가 많아서 기능단위테스트를 수행하기 어려울 수 있으며,
단일 메소드는 단일 함수에 비해서는 수행시간이 많이 걸림. (예를 들어서 모듈YRT분석의 경우 하나의 메소드가 1시간이 걸리기도함)
각 함수마다 저장
함수가 수정되었을 때 함수만 테스트하면 된다는 장점이 있음
하지만 대상 함수가 매우 많으며, wf마다 데이터를 저장하기가 어려운 편
과정
- 브랜치 통합
- 연관 wf 전체 수행
- 에러여부 확인 후 mr 수락
1) 코드 개발(AI)
2) 연관 wf 확인 및 개별 테스트 후 develop을 개별브랜치에 merge(AI)
3) 데이터를 개발서버내 정해진 곳으로 이관(SI? AI?)
4) MR 요청(AI)
5) 기준정보 동기화(SI)
6) MR 테스트
7-1) 결과를 확인하고 에러 수정(AI)
7-2) 결과를 확인하고 MR 수락 (SI)
의문점
데이터 이관은 통합테스트 이후, 운영 이관되면 지워도 되나?
-> 운영이관하고나면 다음 통합테스트에선 운영 경로를 읽으면 되므로 지워도 이상이 없을 것
** 데이터 이관시 다른 영향 wf의 데이터는 이관하지 않아도 되나? -> 다른 wf의 데이터이관이 필요할 수도 있고, 필요 없을 수도 있으나, 필요한데 이관되지 않았다면 ci에서 실패할 것
결과를 보고 필요하다면 추가 이관 요청 등을 보낼 수 있을 것
<데이터 이관 관점>
이 프로세스대로 정상적으로 이관이 이뤄진다면
테스트 데이터 경로는 운영서버와 완전히 동일한 구조를 이루며
그 경로 안에는 이관 대상 데이터와 테스트 결과 데이터만 남게 됨
그러면 최상위 폴더 하나만 운영서버로 이관해도 전혀 문제 없음
운영서버에 선 반영된 경우에는 데이터 관점에서 문제가 없나?
-> 이미 운영서버에 데이터가 먼저 넘어간 상태이므로, 개발서버로의 mig 없이 운영서버를 보고 테스트를 수행하면 됨
여전히 MR 테스트에서 wf의 전체 job을 수행시킨다는 점은 변하지 않음
테스트 비용 자체는 크게 줄어들지 않는 상황
특히 데이터 이관 과정이 추가되어서 시간이 더 걸릴 수도
다만 자동화로 공수는 줄일 수 있을 것
기준정보 동기화는 아래의 논리를 바탕으로 항상 TEST->DEV->PROD를 수행하려고 하는데 괜찮을까?
1) TEST의 변경사항이 없다면 -> 동기화해도 그대로
2) TEST의 변경사항이 있다면? -> 원래해야 할 작업
연관 wf확인은 수정시 의도하지 않은 wf가 영향을 받는지 확인하는 과정
의도치 않은 wf가 끼어있을 때 기준정보수정/코드수정/데이터재적재 등에 대한 판단은 AI팀에 맡김
**개발 후 확인하는 것보다 확인 후 개발하는게 낫긴하겠다.
다만, 이럴 경우 개발/수정하는 사람은 십중팔구 함수를 쪼개는 식으로 작업을 할 것 같은데 그게 바람직할 지는 잘 모르겠음
CI를 하더라도 테스트 데이터를 올려둘 수는 없기 때문에 CI가 결국 개발서버를 찔러서 bat 파일을 실행시키는 형태가 될 것
-> 굳이 그 정도 수준의 자동화라면 그냥 개발서버에서 쓰는 파이썬 스크립트를 하나 개발하는게 더 나을 수도 있음CI/CD 활용?
-
통합테스트
-
데이터는??
일부 wf는 운영, 일부 wf는 테스트?
테스트서버의 데이터를 반드시 개발서버로 이관시켜 놓게 한다면?
-> 이 상태에서 현재의 left_join_file_list 함수를 사용하면 필요한 데이터를 활용하여 사용 가능
그럼 정규이관시 데이터이관도 편하긴 할듯
다만 단점이라면 굳이 테스트만을 위한 데이터 마이그가 필요하다는 정도?
만약 이걸 한다고 가정한다면)
데이터 이관을 하는 경우에만 데이터 마이그를 하도록
그리고, 개발서버에 마이그 된 데이터는 무조건 정규이관시 운영서버로 마이그
-> 데이터 마이그할 때 신경쓸 부분이 줄어들긴 할 듯
genbi는 어떻게 했었지?
- ISSUE 등록
- 담당자, 브랜치, 마일스톤( 1.15 ver까지 하겠다) 등록 및 MR 생성
- 개별 작업 및 push
- 코드 리뷰
- 3명 이상 추천 받으면 MR 수락
- 마일스톤 마감일이 되면 운영에 merge
-
자동분석과의 차이점
자동분석의 이관 싸이클이 더 짧다.
수행 프로세스가 선형적이라서 테스트시 전후관계 영향을 받는다.
복수의 wf가 있어서, wf 수만큼의 테스트가 필요하다.