비품 및 셀레늄 및 레일

Question

Rails 앱에서 Selenium 테스트와 어떤 데이터를 사용합니까? 비품에서 로딩합니까? 기존의 dev db를 사용 하시겠습니까? 별도의 (조명기가 아닌) db를 사용 하시겠습니까?

여기 내 옵션을 고려하고 있습니다. Selenium Grid의 수정 된 버전에서 실행되는 대규모 셀렌 테스트 스위트가있는 Rails 앱이 있습니다. 현재 프로세스의 일부는 테스트 스위트가 실행되기 전에 한 번 큰 세트의 조명기를로드하는 것입니다. 그것은 많은 데이터입니다. 그것의 대부분은 우리의 생산 DB에서 수출 된 정보를보고합니다. 원래 설정을 마치면 Oracle에서 데이터를 yaml로 내 보냈습니다.

이제 일부보고 테이블에 스키마 변경이 있었으므로 물론 조명기 데이터를 다시 생성해야합니다. 파일을 손으로 편집하는 것은 가치가 없다는 점이 너무나 많습니다. 그러나 모든 작은 스키마 변경에 대해 재생성을해야하는 것은 비효율적 인 것처럼 보입니다. 물론 기억해야 할 또 다른 단계입니다. 더 좋은 방법이 있습니까?

EDIT : 필자는 원래 각 테스트 전에 조명기를로드하고 일반 레일 테스트와 같이 각 테스트 후에 조명기를 언로드하려고했습니다. 그러나이보고 데이터로 인해 조명기를로드하는 데 약 15 분이 걸립니다. 200 개 이상의 테스트가 있으며이 제품군은 12 시간마다 실행됩니다. 나는 cannae 우주 시간 선장을 구부린다!

EDIT 2 : 또한이 큰 세트의 조명기는 나쁜 냄새가 나는 것에 동의합니다. 보고서가 많은 데이터를 집계하고 셀레늄 테스트의 가치 중 상당 부분이 보고서를 테스트하기 때문에 어떻게 처리해야할지 모르겠습니다.

데이터 세트가 작은 경우에도 스키마 변경 사항과 조화를 이루는 또 다른 세트입니다. (유닛, 기능 및 [Rails] 통합 테스트를위한 별개의 작은 세트가 있습니다.)

직접 원래의 질문으로 돌아갑니다. 수동으로 수행하거나 각각을 다시 생성하는 것 외에 다른 옵션이 있습니까? 시각?

Answer 1

할 수있는 가장 좋은 방법은 각 셀렌 테스트가 자신의 데이터 상태 (예 : DB 테이블 삭제 및 다시 작성, 부트 스트랩 데이터 다시 삽입, 캐시 지움)를 얻는 시스템을 갖추는 것입니다. 이것은 말하기가 쉬우 며 일반적으로 프로젝트가 처음부터 계획을 세운 경우에만 가능합니다.

다음으로 가장 좋은 방법은 각 테스트 스위트/실행에 대해 일관된 DB 상태를 유지하는 것입니다. 이전에 실행 한 테스트의 성공 여부에 따라 일부 테스트가 달라질 수 있으므로 실제 실패와 위음 방지를 식별하기가 더 어려워 졌기 때문에 이것은 좋지 않습니다.

최악의 경우 IMO는 각 테스트 실행에서 날짜가 변경되는 정적 DB를 사용하는 것입니다. 이것은 거의 항상 문제를 야기하며 대개 "프로젝트 냄새"입니다."올바른 방법"(다시 말하면, IMO)을 수행하는 핵심은 모든 상태/스키마 변경에 대해주의를 기울여 자동 테스트/빌드 프로세스의 일부로 캡처하는 것입니다.

레일즈는 이미 마이 그 레이션과 함께 잘 작동하므로 활용 해보십시오! 귀하의 상황을 모른 채 일반적으로 전체 DB의 스냅 샷에 대해 Selenium 테스트를 실행할 필요가 있는지 질문합니다. 자동화 된 테스트를 위해 대부분의 DB를 1MB 미만으로 증량 할 수 있으며 자동화 된 스키마 마이그레이션 및 데이터 재설정이 훨씬 효율적입니다.

Selenium 테스트를위한 대용량 DB의 "유효한"이유는 데이터 자체가 응용 프로그램의 흐름에 영향을주는 "논리 데이터"의 큰 덩어리를 포함하고 있다는 것입니다 (데이터 중심 UI).

Answer 2

현재 엄청난 셀 룰룸 테스트 슈트가있는 프로젝트에 있습니다. 실제로 셀레늄 그리드는 작성되었지만 테스트에서는 소량의 참조 데이터를 사용합니다 (레일 YAML 비품을 사용하지는 않지만) 및 특정 테스트에 필요한 일회용 데이터에 대한 객체 팩토리를 제공합니다.

다른 ThoughtWorks Rails 프로젝트에서 나는 커밋을 허용하기 전에 테스트를 실행하는 것과 같이 미리 커밋 된 여러 가지 훅을 통합 한 체크인 스크립트를 작성했습니다. 한 가지 고려해야 할 것은 스키마 변경을 확인하고 필요할 때 참조 데이터를 다시로드하는 유사한 체크인 스크립트를 작성 (또는 사용자 정의)하는 것입니다.

Paul Gross의 rake commit tasks, Github.

Answer 3

나는 내가 그것을 무너 뜨리는거야, 그래서 만약 당신이 얽혀 여기에 두 가지 질문을 것 같아요 :

• 당신은에 당신의 DB에서 신속하게 테스트 데이터를 얻으려면 및 비품이 없습니다 너를 위해서 해.
• 당신은 스키마 변경에 의해 태워 봤는데 당신은 당신이 "여전히 ... 테스트 데이터 손보는"테마 여덟 반복을 필요로하지 않는 무엇 이건이 있는지 확인하려면 :

당신을 ' 나는 아래에서 해치 우었던 몇 가지 대안을 여기에서 얻었다. 당신이 오라클을 언급했기 때문에 나는 여기에 오라클 기술을 사용하고 있지만, 같은 일이 다른 DB 플랫폼 (예를 들어, PostgreSQL을) 마찬가지입니다 : 데이터를 생성하는 PL/SQL 스크립트를 호출

1. 레이크 tesks, 불쾌한 끔찍한 악 아이디어, 다른 옵션이 없다면하지 마십시오. 몇 가지 인프라 아키텍처 테스트를 위해 수십억 개의 행을로드해야하는 프로젝트에서이 작업을 수행했습니다. 나는 아직도 그것에 대해 어설프다.
2. DB를 덤프 형식으로 만드십시오. 빠른 이진 덤프는 exp/imp 및 데이터 펌프 유틸리티를 확인하십시오. 이렇게하면 DB를 신속하게 설정하고 해체 할 수 있습니다. 물론 필자가 작업 한 레일 프로젝트에서 분당 300k 레코드를 가진 데이터베이스를 exp/imp하기 위해 레이크 작업을 사용했습니다. 또한 논리적 덤프 유틸리티 인 SQL Loader를 논리가 느린 것으로 확인하고 SQL Loader가 덤프를 이해할 수 있도록 제어 스크립트가 있어야합니다. 그러나 논리적 덤프의 이점은 데이터를 최신 형식으로 마사지하기 위해 변환 스크립트를 실행할 수 있다는 것입니다. 슬프게도 비품과 마찬가지로 모든 도구는 스키마에서 매우 민감합니다.
3. Machinist 또는 Factory Girl과 같은 플러그인을 사용하여 데이터 생성을 더 좋게 만듭니다. ActiveRecord를 사용하여 DB를 설정하는 데는 여전히 불이익을 받지만 이러한 가짜 개체 생성기를 사용하면 마이그레이션에 가까이 가지 않고 유지 보수하는 것이 번거롭지 않게됩니다.
4. 결합 방법 2와 3을 결합하십시오. 여기서 일어나는 일은 Machinst라고 말하면서 몇 가지 테스트 데이터를 만드는 것입니다. 해당 테스트 데이터를 덤프로 내 보낸 다음 각 테스트 실행 중에 덤프를 다시로드합니다. 스키마가 변경되면 Machinist 구성을 업데이트하고 다시 내 보냅니다.

희망이 있습니다.