셀레니움 - 테스트 자동화 3편

 

2편에 이어서 테스트 자동화 관련된 마지막 포스팅이다. 2편 예제에서 언급했던 Page Object (페이지 객체)를 알아보고 이것이 어떻게 테스트 코드에 쓰여야 하고 쓰이는지 예제를 통해 알아보고 테스트 자동화에 대한 정리를 해보도록 하자.

이어지는 내용이므로 2편을 읽지 않았다면 먼저 보기를 권장한다.

 

Page Object Model (페이지 객체 모델)

일단 Page Object(페이지 객체) 모델은 나중 포스팅에서 더 자세히 살펴보도록하고 지금은 간단한 개념을 소개하겠다.

테스트는 웹 사이트의 페이지 내에서 사용자의 관점에서 수행되는 작업으로 구성되어있어야 한다. 이 페이지는 객체로 저장되고 여기에는 웹 페이지 구성 방법과 작업 수행 방법에 대한 구체적인 정보가 포함되어 있다. 이 중 테스터로서 귀하와 관련된 정보는 거의 없다. 테스터가 알고 있어야 할 점은 극히 드믈다는 것을 알 수 있다.

어떤 종류의 유니콘을 원할까? 분홍색 유니콘을 잘 나갈지 모르지만 꼭 그럴필요는 없다. 최근에 인기가 많아진 것은 보라색이다. 

 

유니콘이 선글라스를 씌어볼까? 별 모양 문신? 이러한 선택은 어렵지만 테스터가 관심 있게 봐야 하는 것은 주문 시 올바른 사람에게 그 사람이 꾸민 유니콘을 발송하게 하고 위와 같은 선택을 할 수 있게 보장해야 한다는 것이다.

체크박스, 셀렉트박스(드롭다운), 라디오 버튼 또는 form(폼)에 대해서 언급하지 않았다는 점을 알아차렸을 것이다. 테스트 코드 역시 그래야 한다. 문제를 해결하려는 사용자처럼 코드를 작성하려 해야 한다. 아래와 같은 방법을 참고하도록 하자. (2편 코드와 이어진다)

 

// Unicon은 최상위 객체이다. 유니콘의 속은 생성자를 호출하여 설정 하도록 했다.
// 속성은 여기서만 저장되고 웹 브라우저를 사용해서 속성 정보를 받아오거나 하지 않는다.
Unicorn sparkles = new Unicorn("Sparkles", UnicornColors.PURPLE, UnicornAccessories.SUNGLASSES, UnicornAdornments.STAR_TATTOOS);

// 이미 "내 계정" 페이지를 보고있으니 "유니콘 꾸미기" 페이지로 넘어가도록하자.
// addUnicorn() 메서드가 그런 역할을 한다.
AddUnicornPage addUnicornPage = accountPage.addUnicorn();

// 이제 "유니콘 꾸미기" 페이지에 도착했다.
// 유니콘 객체 "sparkles"를 createUnion() 메서드에 넘겨주도록 하자
// 그러면 유니콘 속성정보를 사용하여 form에 입력하고 submit 버튼을 누를 것이다.
UnicornConfirmationPage unicornConfirmationPage = addUnicornPage.createUnicorn(sparkles);

 

위 코드와 같이 유니콘 꾸미기를 완료하였다. 이제 3단계로 넘어 갈 수 있다. 하지만 그전에 확실히 작동하는지 확인하는 코드를 작성하도록 하자.

 

// UnicornConfirmationPage의 exists() 메서드는 유니콘 객체 "sparkles"를 받아서 
// 유니콘의 스펙 정보를 현재 웹 페이지의 필드에 입력되어 있는 값과 비교를 한다.
Assert.assertTrue("Sparkles should have been created, with all attributes intact", unicornConfirmationPage.exists(sparkles));

 

테스터는 유니콘 객체를 생성하고 비교하는 등의 소소한 작업만 했다는 것을 주목하도록하자. 버튼, 로케이터, 브라우저 제어 장치도 사용하지 않았다.

 

이 테스트 모델링 방법은 만약 다음 주에 길동이가 Ruby-on-Rails가 싫어져서 하스켈 벡엔드와 포트란 프런트엔드로 연동한 애플리케이션으로 재작성하는 것을 결정하더라도 위 테스트는 정상적으로 작동할 수 있다는 것을 보장해 준다. 

Page Object(페이지 객체)는 사이트 재설계를 준수하기 위해 약간의 작은 유지보수가 필요하지만 이러한 테스트는 그대로 유지된다.

 

이 기본 설계를 사용하면 브라우저를 사용하는 테스트를 가능한 최소한으로 줄일수 있고 다음 단계의 워크플로우를 계속 진행할 수 있게 해 준다. 다음 단계의 워크플로우는 꾸민 유니콘을 장바구니에 추가하는 것이다. 장바구니가 정상적으로 작동하는 것을 보장하기 위해서 아마도 테스트를 여러 번 반복할 것이다.

 

예를 들면 추가하기 전에 장바구니에 몇 개의 유니콘이 담겨있었나? 장바구니에 최대 몇 개가 들어갈 수 있나? 이름/속성이 똑같은 유니콘을 만들면 어떻게 될까? 중복으로 처리할 것인가 별개의 상품으로 인식해야 할 것인가 등등...

 

각각 워크플로우를 실행할때마다 계정에 로그인하거나 새로 만들고 유니콘을 다시 꾸미지 않도록 해야 한다. 이상적으로는 API나 데이터베이스를 사용하여 계정을 생성하고 유니콘을 미리 꾸며놓을 수 있다. 그런 다음 사용자로 로그인하여 "sparkles" 유니콘을 찾아 장바구니에 추가하기만 하면 된다.

 

테스트 자동화 해야할까? 말아야 할까?

테스트 자동화가 항상 좋을까? 언제 테스트 자동화를 결정해야 할까?

 

테스트 케이스를 자동화하는 것이 항상 유리한 것은 아니다. 매뉴얼 테스트가 더 적절할 때가 있다. 예를 들면 애플리케이션의 사용자 인터페이스가 가까운 미래에 상당히 변경될 경우에는 자동화된 테스트 케이스를 모두 다시 작성해야 할 충격과 공포스러운 일이 있을 수 있다.

 

때로는 테스트 자동화를 구축하기에는 시간이 충분하지 않을 때도 있다. 일반적으로 보았을때 단기적으로는 매뉴얼 테스트가 더 효과적이다. 어플리케이션 프로젝트의 기한이 매우 촉박한 경우에 현재 사용할 수 있는 자동화된 테스트가 없으면 매뉴얼 테스트를 하는 것이 기간 내에 테스트를 필수적으로 끝내야 하는 경우에 가장 최선의 선택이다.