바빠던 테스트 수행이 끝나고 실습을 할 수 있는 시간이 주어졌다. 3일정도 회사의 selenium 코드를 보면서 하기 기능에 대한 자동화 코드를 작성하였다.
그룹웨어 도메인의
- 로그인 & 메일
WMS 도메인의
- 출고상품 단건 등록
- 출고상품 엑셀 대량 등록
아직 잘 모르지만 어떻게 하면 자동화를 잘 만들 수 있는지 궁금증이 마구마구 생기고 있다.
-
자동화용 케이스의 정제 작업
두루뭉실하게 적혀있을 경우 화면 상에 요소가 노출되는 부분을 판단하는 assertion 다르게 정의될 수 있을 것 같다. 어떻게 하면 부족한 시간 내에서 잘 설계할 수 있을까? -
테스트 코드로 작성된 함수명을 판별하는데 시간이 오래걸린다
작업자에 따라 함수명 작성법이 달랐다. 테스트 코드를 함수명으로 작성하면 테스트 케이스 작성에 용이하지만, 특정 기능의 코드를 찾을 때 시간이 더 걸렸다.
기능 위주의 함수명은 코드 찾기는 편했지만, 설계면에서 가독성이 떨어지는 면이 있었다. -
element 찾는게 어려워!
중첩된 iframe 구조를 가지고 있을 때마다 난감해졌다. iframe이 5개가 넘어갈 때의 기분이란..
그리고 지금은 일단 실행만 되게하자 생각하고 절대경로 XPATH 마구마구 때려 넣고 있는데, 동적변화에 덜 예민한 element 찾는 법을 사용하는 습관을 들여야 한다.
By.ID- root 이므로 가장 속도가 빠르다.
- 동적인 환경에서 설정이 어려운 경우가 있음.
By.XPATH- 다른 방법들에 비해 속도가 느리다.
- 복잡한 DOM 구조에서도 정확히 찾을 수 있음.
- 코드가 읽기 어렵기 때문에, 짧고 간결하게 표현하는 것이 중요함. 따라서 절대경로보다 상대경로를 권장.
By.CSS_SELECTORBy.XPATH보다 속도가 빠르고 다양한 선택이 가능.- 동적인 환경에서 유용.
- 속도와 동작중 뭐가 뭐가 중요하지?
테스트 수행시간이 단축되는 것이 중요하다고 생각했기에 특정 element를 식별할 때 time.sleep() 사용을 최소화했다. 다 다만, 코드 리뷰에서 time.sleep()을 사용하는 것이 때때로 더 안정적이라는 의견을 받았다. 자동 점검이 FAILED하면 결국 말짱도루묵인 셈이니 말이니 말이다.
적절하게time.sleep()을 사용해서 속도와 동작 사이의 적절한 타협점을 찾도록 해야할 것 같다.
개인적으로는 결제 프로세스도 진행해 보았는데
결제 수단이 많아서 하나의 은행사만 선택하여 시나리오를 작성해서 진행했었다. 이렇게 하나의 프로세스안에 분기가 많은 경우는 어떻게 테스트 코드를 짜는지 궁금했는데,,
@dahunyoo/서비스-UI-테스트-자동화-시작-후기
주옥같은 글을 발견했다! test-suit 구조로 고치면 다른 케이스도 쉽게 구현할 수 있는 확장성 있는 테스트 코드를 만들 수 있을 것 같다.
