테스트 자동화 Cypress

올해 PI(Program Increment)의 목표 중 하나는 모든 테스트의 자동화이다. 시스템이 워낙 커지다 보니, 릴리즈 전/후에 모든 기능을 스모크 테스트가 불가능하다 보니 도입한 것이 아닌가한다. 일단 모든 Happy Path에 대한 기능을 릴리즈 전 자동화로 테스트하여 릴리즈 전에 버그나 잘못된 기능을 찾아내는 것이다. 아무리 유닛 테스트를 많이 작성한다고 전체 기능을 다 커버리지 할 수 없으니 당연하다고 볼 수 있다. 유닛 테스트는 통과하더라도 컴포넌트 테스트나 실제 통합 테스트에서는 통과하지 못하는 경우들이 왕왕 있기 때문이다.

내가 기존에 알고 있던 테스트 자동화 툴은 셀레니엄 밖에 없었는데, 이번에 회사에서 Cyress를 이용해서 모든 기능을 테스트 자동화를 도입하고 있다. 정확히 말하면 QA들이 일부 기능에 대해서는 이미 만들어 놓았는데, 일부가 아닌 전체 기능에 대해 적용을 하려고 하고 있다. 이 업무가 모든 개발자에게 주어지기 시작했다. 자신이 만든 기능에 대해서는 무조건 테스트 자동화를 만들 것! 일단, 시나리오는 QA가 작성해 주고 이를 바탕으로 Happy Path에 대한 테스트를 자동화하면 되는 것이다.

이번에 처음 Cypress를 사용해 보았는데, 의외로 괜찮은 것 같다. 셀레니엄은 예전에 설치에서 포기했었는데, Cypress는 npm 기반으로 쉽게 설치 가능하고 바로 코딩이 가능하다는 점이다. 다만, 문제가 되는 것은 각 Element에 대한 Selector를 선택해야 하는데 이게 워낙 골치 아픈 일이 아닐 수 없다. 특정 엘리먼트가 ID나 자신만의 class를 가지고 있다면 쉽게 Element를 찾을 수 있겠지만, 그렇지 않은 경우 크롬 개발자 도구를 열어 일일이 엘리먼트 계층 구조를 파악해서 찾아내야 한다. 예를 들어 Toggle 버튼이 50개 있고 그 Toggle에 대해 ID가 없다면 Toggle 라벨을 이용하던, 순서를 보던, 어떤 방법으로든 그 Toggle 버튼의 Element를 찾아내야 하는 것이다. 지금 있는 시스템의 경우 대부분 엘리먼트에 ID가 존재하지 않고, Knockout으로 만들어진 것들이 많아 하나의 커다란 페이지에서 유일한 엘리먼트를 찾아내는 작업이 워낙 괴로운 작업이었다. 하지만, QA에게 데모를 해 주었더니 대만족이라지만, 개발자는 해야할 일이 한가지 더 늘어났으니, 으휴...

이런 치명적이고 단조로운 작업의 귀찮음 때문에 Cypress 대체품을 다른 팀에서 열심히 찾아본 모양. 옆팀의 시니어 개발자가 좀 보여줄게 있다고 하면서 Cypress 대신 Relicx라는 제품을 사용하는 것이 어떻겠냐고 하면서 나에게 데모를 보여 주었다. End To End 테스팅을 만드는 것이 코딩 베이스가 아닌 UI 베이스로 돌아가게끔 되어 있었다. 엘리먼트 선택도 UI에서 Action도 UI에서 모두 Flow를 만들어 놓고, Assert도 UI에서 설정. 약 일주일 넘게 Cypress로 개고생 해 본 나로써는 거의 신세계급 수준의 테스팅 툴로 보이더라. 하지만, 상용 제품이라 돈을 지불해야 한다는 것! 내 프로젝트가 아니니 돈에 대해 신경 쓸 필요는 없으니, 당연히 난 Relicx로 가는게 맞고 쿨한 툴 같다고 얘기해 주었다.

암튼, End To End 테스팅 프레임워크를 찾고 있고 비용에 제약이 있다면 Cypress가 좋은 대안이 될 수 있겠다. 물론 UI 개발자에게 ID 값을 할당하라는 점을 잊지말고 상기 시켜야 한다.

Cypress 프레임워크 홈페이지는 여기에서

https://www.cypress.io/

JavaScript Web Testing and Component Testing Framework | cypress.io