[개발일지] - 472

Form 관련 테스트클래스를 빠르게 마무리했는데

어제 들었던 리팩토링이 생각나서 테스트클래스 내부에 assertEquals를 사용해서 간단하게 내용 체크를 진행했다.

        List caseList = [SELECT Field1, Field2, Field3 FROM Case WHERE Field1 = 'xxxx'];
        System.assertEquals(1, caseList.size());
        System.assertEquals('Email', caseList[0].Field1);
        System.assertEquals('기술', caseList[0].Field2);
        System.assertEquals('ABC', caseList[0].Field3);

        List files = [SELECT FileName__c, DownloadLink__c FROM FileObjectName WHERE FileName__c = 'testData1'];
        System.assertEquals(1, files.size());
        System.assertEquals('testData1', files[0].FileName__c);
        System.assertEquals('<https://uatName.sandbox.file.force.com/sfc/servlet.shepherd/version/download/fileId>', files[0].DownloadLink__c);

 

간단하게 추가 하고 확인하는데 에러가 발생해서 테스트클래스 자체가 죽어버렸고

원인을 파악해보니 그냥 테스트 커버리지는 나오지만 실제 입력이 되지 않는 필드가 있었고

결국 해당 필드값을 고쳐주니 정상적으로 통과하는 것을 볼 수 있었으며

다른 테스트클래스의 경우 여러개를 동시에 작성하다보니 다른 인터페이스의 경로를 넣어버렸는데

그래서 생성 자체가 안되서 에러가 발생하는 것도 빠르게 발견할 수 있었다.

 

확실히 커버리지만 채우는 것이 아니고 세부 내용 확인을 하는 것도 중요하다는 생각이 들었고

일부 필드값이 변경되거나 할 때 발생할 에러도 미리 확인할 수 있을 것 같았다.

 

Form 테스트클래스들을 전부 마무리 후 추가 확인까지 작성해준 다음

중간에 회사 명칭을 어떻게 진행할지에 대한 문의사항에 답변을 해주고

점심시간 직후 진행하는 리팩토링 스터디에 참여했다.

 

이번엔 밑줄 강의를 들으며 밑줄을 그어야 하는 시간이었지만

말 속도가 조금 빠르긴 했고 살짝 설명이 체계적이지 못했기 때문에

따라가지 못하는 분들이 생겨서 어쩌다보니 그냥 밑줄 자체가 취소되게 된 것 같았다.

 

밑줄이면 밑줄, 네모나 동그라미면 네모나 동그라미 등

먼저 할 행동을 지정하고 읽어나가야 했는데

읽어 나간 후 행동 지시 그리고 바로 다음 페이지나 문단 등 위치 이동을 하기 떄문에

어지간하면 놓치지 않는데 세번정도 놓칠뻔했다.

 

중간에 미생성 관련 인터페이스 문의가 날아왔지만

이번에도 역시나 전송된 로그가 존재하지 않아 SAP 문제 같다고 로그를 첨부했고

한참 뒤 날아온 결과는 발송 로직이 그 부분이 없어서 수정되었다고 했다.

 

이쪽 SAP만 문제인건지

아니면 내가 주 고객사로 관리하는 인터페이스가 여기라서 여기만 문제처럼 보이는건지

어쨌거나 하루 1~2회 인터페이스 오류 문의가 날아오는데

한두달에 한번쯤을 제외하면 다 SAP 문제라 사실 이제 로그를 찾아보는 행동 자체도 귀찮아진다.

 

회원가입 시 계정과 연결하는 부분에 대해 고객사가 의문을 품었는데

Lead와 Contact의 차이인 회사 명칭 부분을 이해하지 못하신 것 같아서

예제외 Lead to Contact 변환 내용을 보여주며 설명드렸다.

 

Lead는 실제 연결된 사람이 아니고 미확정 상태에 가깝기 때문에

회사 자체가 등록되지 않았거나 미정인 상태일 수 있어서 text로 관리되고

Contact 부터는 실제 연락처로 관리되기 때문에 계정이 필수적인 구조로

변환 페이지에서도 직접 Account를 선택해야 하는 부분도 캡쳐해서 전달드리며

계정이 필수적으로 들어가기 떄문에

SFDC 내부에 있는 계정의 중복을 제거하거나

동일 명칭 랜덤한 계정에 연락처가 들어가거나 하나를 선택해야 한다고 전달드렸다.

 

완료된 Form 인터페이스 배포 가능 여부도 미리 체크했는데

황당하게도 리팩토링을 배운 김에 추가했던 추가 확인 내용에서 에러가 발생해버렸는데

로그를 찍어가며 확인해본 결과 trigger등에서 추가 절차 중 에러가 발생했고

다른 모든 트리거를 고려해가면서 테스트클래스를 내용을 작성할 수는 없기 때문에

아쉽지만 에러가 발생하는 2개 인터페이스는 assert 부분을 주석처리했다.

 

기존 홈페이지에 이미 중복없는 계정이 있는데 어디서 온건지 문의를 하셔서

SAP쪽이 아니겠냐고 대답하려고 하다가

1년쯤 전 해당 협력사쪽에 계정 조회 인터페이스를 넘겨준 기억이 문득 스쳐지나갔고

인터페이스를 확인했지만 다행히 기간별 특정 조회라 그 내용은 아닐 것 같긴 했다.

 

Account를 예전 코드에서 가져가는지

아니면 SFDC REST API를 사용하는지

그것도 아니면 SAP에서 받아서 사용할건지 모르기 때문에 문의를 남겨두고

연락처 생성은 확정적으로 진행될 것이기 때문에 인터페이스를 개발했다.

 

개발 후 postman 수신 테스트와 정의서 작성까지 마치니 퇴근시간이라 준비하고 있었는데

다른 회사 인터페이스 업무가 추가로 들어온다고 해서 내일도 바쁘게 진행될 것 같다.

 

사실 인터페이스 업무야 얼마든지 처리하는게 맞는데

비인터페이스 업무가 잔뜩 쌓여있지만 고객사에서 재촉하지 않기도 하고

애초에 지금 하는 작업 대다수는 그 고객사쪽의 홈페이지 이전 인터페이스기 때문에

급한 일이 들어오면 그냥 급한일들을 먼저 하게 되는 것 같다.

 

 

(1).백준 30596번 Axis-Aligned Area는 평행하는 직선들로 둘러쌀 수 있는 최대 넓이를 구하라는 문제였는데

사실상 만들 수 있는 직사각형을 묻는 문제라고 볼 수 있고 가장 작은 수와 세번째 작은 수를 곱해서 해결 가능한 문제로

입력된 값을 정렬해서 첫번째인 a, 세번쨰인 c를 곱하는 방식으로 해결했다.

 

다만 js의 경우 sort는 멋대로 사전식 정렬이 되는데

알고는 있었지만 오랜만에 sort를 써서 숫자는 괜찮을 것 같다고 생각하고 썼는데

하필 예제는 10단위가 없어서 오답이 나온 다음 숫자를 아래 예시와 같이 변경해서 에러가 발생한 것을 확인 후 

sort()가 아니라 sort((a,b) => a-b)로 바꿔서 숫자순 정렬이 되게 변경해서 해결했다.

const [a,b,c,d] = `11
1
100
13`.split('\n').map(Number).sort((a,b) => a-b)

console.log(a * c)