사소하거나 외형적인 변화로 실패하지 않는 셀레늄 (또는 유사한) 테스트를 어떻게 작성할 수 있습니까?

지난 주에 셀레늄을 배우고 출시하려는 웹 사이트에 대한 일련의 웹 테스트를 작성했습니다. 배우는 것이 좋았으며 xpath 및 CSS 위치 기술을 선택했습니다.

그래도 문제는 작은 변경으로 인해 테스트가 중단되는 것을 볼 수 있습니다-div, id 또는 위젯을 식별하는 데 도움이되는 일부 autoid 번호에 대한 변경은 매우 많은 테스트를 중단합니다.

따라서 셀레늄 (또는 다른 유사한) 테스트를 작성했으며 테스트의 취성 특성을 다루는 방법 (또는 취성을 막는 방법)은 무엇이며 셀레늄은 어떤 종류의 테스트를 사용합니까?

Selenium의 목적은 UI 기반 통합 테스트 를 작성하는 것입니다 .

통합 테스트는 함께 배포 할 때 시스템의 모든 구성 요소가 올바르게 작동하는지 확인합니다. 통합 테스트는 충분한 테스트 전략이 아니며 단위 테스트 및 승인 테스트 와 같이 다른 초점을 가진 다른 테스트 전략을 보완 합니다.

UI 기반 테스트는 본질적으로 취약하지만 Selenium과 Watir는 초기 기록 및 재생 도구 에서 한 단계 업그레이드되었습니다 . 이 문제를 해결하는 방법은 여러 가지가 있습니다. 다음은 세계적 수준의 전문가들이 제공하는 조언입니다.

이 유형의 테스트에서 모든 테스트 범위를 확보하려고 시도하지 마십시오 . Robert C. Martin 은 통합 테스트에 의한 코드 범위는 약 20 % 여야한다고 주장합니다 . 입력이 여러 애플리케이션 계층에서 떨어져있을 때 모든 실행 경로를 테스트하는 것은 비현실적입니다.

단위 및 합격 시험에서 대부분의 시험 범위를 확보하십시오 . FinnNk 의 답변 에서 Gojko Adzic의 기사에 대한 링크를 찾으십시오 . Adzic은 수용 테스트 및 우회 UI를 통한 비즈니스 로직 테스트에 대해 반복적으로 주장했습니다.

그러나 일부 UI 기반 테스트는 여전히 작성해야합니다 . 여기에는 "UI를 통해 비즈니스 로직을 테스트하지 마십시오"외에도 실용적인 조언이 필요합니다. 내가 권하고 싶습니다 패트릭 윌슨 - 웨일스의 블로그를 시작 지점으로.

사소한 수를 지나면 이와 같은 테스트를 만들 때 가장 중요한 것은 대칭 변경이라는 아이디어입니다. 코드를 조금만 변경하면 테스트 스위트가 약간 변경됩니다.

예를 들어 100 번의 테스트에서 두 개의 텍스트 상자를 가진 사람의 이름을 수집한다고 가정 해 봅시다. 이러한 테스트를 깔끔하게 작성하거나 레코드 재생을 사용하는 경우 100 개의 테스트를 변경해야합니다. 대신 '엔터 이름'단계를 추출하여 셀레늄을 직접 사용하는 대신 테스트에서 사용하면 한 번만 변경할 수 있습니다. 사용하는 추상화 계층 수에 따라 상황에 따라 달라 지지만 추상화를 사용하면 테스트를 유지 관리하는 데 많은 도움이됩니다.

두 번째로 중요한 것은 선택기가 가장 중요하고 변경 가능성이 가장 낮은 것을 기반으로하는 것입니다. 때때로 이것은 ID 또는 클래스이거나 요소 내부 또는 주변의 텍스트 일 ​​수 있습니다. 항상 가장 간단한 선택기 (예 : id)를 선호하지만 때로는이를 달성하기 위해 xpath와 같은 것을 사용해야합니다.

자신의 체크 아웃 - 그것은 시험의 종류에 관해서 고 이코 애드 직은 자신의 블로그에 좋은 조언을 많이 가지고 죽음의 사인을 하고 어떻게 그것을 방지하기 위해 특히.

테스트는 코드가 예상대로 작동하는지 확인합니다. 테스트가 정기적으로 중단되는 경우 테스트가 올바른 테스트를 수행하지 않거나 개발자가 테스트에 신경 쓰지 않습니다.

개인적으로 <div>태그 의 존재 로 인해 테스트가 중단되면 테스트는 반드시 주변 태그에 엄격하게 의존하므로보다 관대 한 접근 방식을 취해야한다고 생각합니다.