Cucumber-js: 결과에 시나리오 및 태그가 없습니다.

아니요. 테스트 케이스의 태그에 쉽게 접근할 수 없습니다. 이전 시나리오 결과로 돌아갈 계획은 없습니다. 태그가 필요한 사용 사례는 무엇입니까?

제 경우에는 태그 시스템에 의존합니다. 후크에서 일부 데이터를 얻기 위해.

이 같은:

<strong i="7">@SuiteName</strong> <strong i="8">@SuiteSectionName</strong> <- These tags tell the suite
Feature: 

<strong i="9">@TC1563697</strong> <- This tag identifies the testcase in the test management tool <strong i="10">@New</strong>
Scenario: 
    Given  
    When 
    Then 

특정 태그가 있는 시나리오에 대해서만 실행되는 후크를 만들 수 있습니다. https://github.com/cucumber/cucumber-js/blob/v3.0.1/docs/support_files/hooks.md#tagged -hooks

또한 시나리오 태그를 알기 위한 몇 가지 사용 사례가 있습니다. 다음 sudo 예제가 주어지면(1.3.1에 테스트 케이스가 있고 최신 3.0.1을 보고 있기 때문에 버전 구문이 약간 누락됨):

<strong i="6">@set_video</strong> <strong i="7">@youtube</strong>
Scenario: User should see youtube video

<strong i="8">@set_video</strong> <strong i="9">@vimeo</strong>
Scenario: User should see vimeo video


this.After({tags: @set_video}, function (testCase) {
  let tags = testCase.scenario.tags;

_.forEach(tags, (function (tag) {
 if(tag === '<strong i="10">@youtube</strong>') {
   setVideo('youtube');
 }
if(tag === '<strong i="11">@vimeo</strong>') {
 setVideo('vimeo');
}
});

}

후크를 언제 실행해야 하는지 알려주는 태그가 하나 있고 다른 사용 사례에서 작동하도록 후크를 보다 동적으로 만드는 데이터 역할을 하는 다른 태그가 있습니다. 그렇지 않으면 동일한 논리로 동일한 후크를 만들고 전달한 데이터만 변경하게 됩니다. 태그를 아는 것은 후크를 더 유연하게 만드는 데 매우 유용하고 강력한 도구라는 것을 알게 되었습니다.

여기에서 3.0.1의 After 후크에서 결과 개체를 얻을 수 없는 것 같습니다. testCase, 시나리오 결과 및 시나리오를 시도했습니다. 내가 뭔가를 놓치고 있습니까?

TestRail에 테스트 케이스를 보관하고 실행 전에 다운로드하여 기능 파일로 저장하는 경우가 있습니다.

그런 다음 후크에서 자세한 테스트 결과를 SQL 데이터베이스로 보냅니다. 이러한 결과는 다음과 같습니다.

• TestRail의 기능 ID - 태그에서 가져옴(각 기능은 기능 ID가 있는 태그를 자동으로 생성함)
• 던져진 예외 - 오이 1.x의 scenario.getException() 에서 가져옴
• 기능에 태그가 지정된 모든 태그
• 실패한 단계 - stepResult 후크를 사용하여 모든 단계의 결과를 얻습니다.
• 태그에서 가져온 기능 ID를 사용하여 TestRail에서 가져온 많은 다른 정보

따라서 오이 3.x의 현재 변경 사항으로 인해 인프라가 완전히 손상되므로 전환할 수 없습니다.

@pawelus 내 인프라는 정확히 동일한 작업을 수행합니다.
이러한 작업을 비동기식으로 수행해도 아무 것도 잃지 않기 때문에(즉, 실제 테스트 인프라는 TestRail 업데이트에 대해 "관심"하지 않음) 해당 코드를 사용자 지정 포맷터로 이동하고 이벤트에서 오는 정보를 사용할 수 있습니다. 보고서를 작성하고 보내기 위한 프로토콜입니다.

개인적으로 오이를 시작하는 래퍼 스크립트가 있습니다.
오이가 시작되기 전에 TestRail 시나리오를 다운로드하므로 TestRail 보고서 코드를 오이 후크에서 래퍼 스크립트로 옮기는 것은 큰 문제가 되지 않았습니다.
오이가 완료된 후 스크립트는 출력된 cucumberResults JSON을 읽고 거기에서 필요한 모든 정보를 컴파일합니다.

어느 쪽이든 코드를 재정렬해야 할 것 같습니다.
모든 사전/사후 작업을 래퍼 스크립트로 이동하는 것은 V3에서 잃어버린 제어 기능 중 일부를 복원하는 좋은 솔루션이라고 생각합니다.
출력된 결과를 풍부하게 하기 위해 중요한 컨텍스트 정보를 직렬화해야 하므로(관련 코드가 실행될 때 인프라 상태가 파괴되므로) 여전히 다소 고통스럽습니다. 하지만 가능합니다.

후크에서 태그를 아는 능력을 잃는 것은 부끄러운 일이라고 생각합니다. 추가 태그를 추가한 다음 다른 입력으로 함수를 호출하기 위해 현재 시나리오에 적용된 매개변수를 전달할 수 없기 때문에 조금 더 구성 가능하게 만드는 유일한 방법이었습니다.

@yaronassa 우리는 Protractor를 통해 테스트를 실행합니다. 우리는 오이를 직접 실행하지 않으므로 여기에서 계산할 또 다른 추상화 계층이 있습니다.

우리는 당신처럼 각도기가 시작되기 전에 기능을 다운로드하지만 데이터베이스에 결과를 보내는 것은 다른 이야기입니다.

Selenium 그리드에서 실행되는 샤딩 및 테스트와 실패한 기능의 재실행으로 데이터베이스에서 올바른 순서로 결과를 얻는 것은 상당히 번거롭고 복잡한 논리가 될 것입니다. 오이 1과 2에서 우리가 가지고 있던 기능을 복원하기 위한 상당한 양의 작업.

또한 단계 결과를 얻기 위해서만 사용자 정의 포맷터를 만드는 것은 적절하지 않습니다.

이봐, 난 너와 함께있어.
나는 오이의 현재 상태(기능, 시나리오, 단계, 전체 속성 컬렉션 포함)에 대한 무제한 액세스를 원했을 것입니다. ).

오이JS가 이러한 종류의 "내부 가시성"에서 의도적으로 멀어지는 것을 보고, 나는 가까운 장래에 효과가 있을 수 있다고 생각하는 종류의 솔루션을 제공하고 있습니다. 개인적으로, 나는 우리와 같은 땜장이가 이러한 종류의 액세스를 유지하기 위해 Cucumber의 내부에서 내부 메소드를 재정의해야 할 때가 올 것이라고 생각합니다.
그리고 괜찮습니다. 우리는 수십 명이고 일반 사용자는 수천 명에 달합니다.

가능하다면 시나리오의 이름도 뒷받침하겠습니다. 실제로 스냅샷 기능을 추가하고 있으며 내 스냅샷의 이름을 지정하려면 시나리오의 이름을 알아야 합니다.

@gd46 다음을 수행할 수 있습니다.

this.After({tags: "<strong i="7">@set_video</strong> and @youtube"}, function () {
  setVideo('youtube');
})

this.After({tags: "<strong i="8">@set_video</strong> and @vimeo"}, function () {
  setVideo('vimeo');
})

@set_video 플래그를 제외하고는 중복되지 않습니다.

@pawelus

그런 다음 후크에서 자세한 테스트 결과를 SQL 데이터베이스로 보냅니다.

After 후크에서 이 작업을 수행해야 합니까? json 포맷터 결과를 구문 분석하여 테스트가 완료된 후 이 작업을 수행할 수 있습니까? 더 많은 처리가 필요하지만 결과가 발생함에 따라 계속하기 위해 이벤트 프로토콜 포맷터를 사용할 수 있습니다. 3.x 변경 사항의 부산물은 구문 분석 결과가 지원 파일에서 독립 실행형 프로세스로 이동한다는 것입니다. 나는 이것이 사물의 더 나은 분리와 이상적으로 사물이 원래 어떻게 만들어 졌는지 생각합니다.

@bnadim

attach 함수로 스크린샷을 추가하여 이벤트 potocol / json 포맷터에서 출력하도록 한 다음 일부 사후 처리를 수행하여 시나리오 이름을 기반으로 파일에 저장할 수 있습니다. 측면이 아님: 시나리오 이름은 고유하지 않은 반면 시나리오 uri 및 행 번호는 고유합니다.

@charlierudolph 내 요구에 대한 견고한 대체 솔루션이라고 생각합니다. 또한 현재 실행 중인 시나리오를 분석할 필요가 없습니다. 주어진 함수가 후크 내에서 처리할 수 있는 다양한 조합을 설명하는 후크의 여러 조합을 정의할 수 있습니다.

예를 들어 현재 실행 중인 시나리오 태그가 패턴을 기반으로 분할하고 일치의 일부를 함수에 대한 매개변수로 사용하는 유사한 예가 있습니다. 이러한 경우 발생해야 하는 모든 단계는 동일하며 변경되는 유일한 것은 매개변수입니다. 따라서 이것은 후크의 여러 설정 단계를 줄여 여러 경우에 작동할 수 있습니다.

그러한 예:

tags: <strong i="9">@clear_w2OnlyUser</strong>, <strong i="10">@clear_w2OnlyArcotEnableUser</strong>

I split based on <strong i="11">@clear_</strong> and grab the second half as the parameter. tagName coming from the old scenario result of getTags, getName. 

let profileToClear = tagName.split('<strong i="12">@clear_</strong>')[1];

browser.waitForAngularEnabled(false);
browser.get(url);
login();
navigate();
deleteProfile(profileToClear);

이에 대한 생각을 말씀해 주시겠습니까? 나는 당신의 예가 어떤 경우에는 쉽게 대체될 것이라고 믿습니다. 그러나 발생해야 하는 몇 가지 추가 단계가 있는 다른 곳에서는 이러한 모든 단계를 잠재적으로 복제할 수 있습니다.

내 사용 사례는 어떻게 동작해야 하는지 알고 있는 태그를 기반으로 각 시나리오에 대해 mockserver를 설정하는 것입니다. 태그가 지정된 특정 시나리오에 대한 후크를 추가하는 것은 유지 관리가 매우 집약적입니다. 지원하는 각 시나리오에 대한 후크를 추가해야 하기 때문입니다...

또한 시나리오 이름을 기록하기 위해 Before 및 After 후크에서 시나리오.name을 사용하고 있습니다. 이렇게 하면 테스트 결과를 분석할 때 특정 시나리오가 시작되고 끝나는 시점을 알 수 있습니다. 이 변경으로 인해 해당 기능이 중단됩니다.

Cucumber-js를 사용하여 Selenium을 구동하고 있습니다. 로컬 및 Browserstack 모두

나는 많은 필수적인 것들을 위해 후크에서 테스트 상태(기능, 시나리오, 태그, 결과 등)를 사용하고 있었습니다.

• 시나리오별 URL 변경
• 현재 브라우저 구성을 기반으로 동적으로 테스트 건너뛰기
• 시나리오별 URL을 사용하여 Browserstack에 테스트 결과를 다시 기록하십시오.
• 기능 및 시나리오 이름을 사용하여 Browserstack에서 세션 이름 생성
• 태그를 구문 분석하여 시나리오별 브라우저 해상도를 식별하고 설정합니다.

이 모든 것은 동시 인스턴스가 전체 실행 시간을 줄일 수 있도록 앱으로 래핑되었습니다.

왜 이것들이 떨어졌습니까?
그들은 결코 돌아 오지 않을 것입니까?

@gd46

실행 중인 시나리오에 해당 유형의 프로필이 포함됩니까? 어떤 유형의 프로필이 세상과 상호 작용하는지 시나리오를 저장하고 저장된 프로필을 제거하라는 단일 명확한 태그를 가질 수 있습니까?

@justusromijn

모의 서버의 경우 설정을 정의하는 단계를 사용하여 태그 기반에서 설정을 이동할 수 있습니까? 그러면 쉽게 매개변수화할 수 있습니다.

@Jordyderuijter

시나리오 라인과 URI(실제로 고유하고 시나리오 이름을 검색할 필요가 없음)를 기록할 수 있습니다.

@leggebroten

시나리오별 URL 변경

대신 이 단계를 사용하거나 고유한 태그를 사용할 수 있습니다.

현재 브라우저 구성을 기반으로 동적으로 테스트 건너뛰기

어떻게 동적으로 테스트를 건너뛰고 있었습니까? #912에 대한 지원 추가

시나리오별 URL을 사용하여 Browserstack에 테스트 결과를 다시 기록하십시오.

이름 대신 line과 uri를 사용할 수 있습니다. 앞에서 언급했듯이 line과 uri는 고유하지만 이름은 고유하지 않습니다. 또한 테스트 결과를 위해 json 포맷터 또는 이벤트 프로토콜 포맷터 포맷터를 구문 분석하고 추가해야 할 사항이 있으면 첨부 파일을 사용하는 것이 좋습니다.

기능 및 시나리오 이름을 사용하여 Browserstack에서 세션 이름 생성

라인 + URI를 사용할 수 있습니다.

태그를 구문 분석하여 시나리오별 브라우저 해상도를 식별하고 설정합니다.

이를 위해 단계를 사용할 수 있습니다.

이 모든 예에서 후크에 다시 태그나 이름을 추가해야 한다고 확신하는 사용 사례는 아직 없습니다. 태그와 이름을 사용하면 특정 작업을 더 쉽게 수행할 수 있는 것처럼 보이지만 더 의미가 있는 작업을 수행할 수 있는 다른 방법이 있다고 생각합니다.

@charlierudolph 답변 감사합니다. 모의 서버의 경우 이미 일부 동료와 빠른 대화를 나눴고 공유 "배경"을 사용하는 것이 솔루션을 고려하고 있었기 때문에 목록 중 하나를 넘을 수 있습니다.

@charlierudolph 답변 감사합니다.

단계를 사용하고 출력을 구문 분석하라는 제안이 작동할 수 있지만 콜백이 상태 테스트에 액세스할 수 있는 이전 버전보다 훨씬 열등합니다.

0) 관찰자 패턴과 일치하지 않습니다. 콜백은 지원하는 동작에 필요한 데이터를 제공해야 합니다.

1) 극도의 취약성을 유발합니다. 테스트는 신뢰할 수 있어야 합니다. 그렇지 않으면 신뢰할 수 없습니다. 줄 번호와 파일 이름이 변경됩니다. 단순히 캐리지 리턴을 추가하거나 제거하면 테스트가 중단됩니다.

2) 단계를 사용하여 상태를 변경하는 것은 DRY를 위반합니다. 태그로 표시된 A/B 테스트를 자주 추가하는 경우를 고려하십시오. 포함된 단계를 기반으로 테스트를 실행하기 위해 명령줄 확장을 추가하지 않는 한 테스트에는 태그와 지원하는 상태 변경 단계가 모두 필요합니다.

3) 개발자가 추가 작업을 수행해야 합니다. 상태를 찾기 위한 출력 구문 분석은 불필요하고 지루하며 오류가 발생하기 쉽고 테스트를 출력 형식(빈약한 커플링)에 바인딩하고 DRY를 위반합니다.

4) 오이와 일치하지 않습니다. 기능의 상태를 변경하기 위해 단계(테스트의 의미론적 부분)를 추가하는 것은 격리 테스트 작성자의 의도에 위배됩니다. 동작이 변경되지 않은 경우 테스트는 변경되지 않아야 합니다.

5) 선언적이지 않습니다. 태그는 테스트에 대한 메타데이터이며 테스트가 실행될 상태를 변경하는 데 태그를 사용하는 것이 의미적으로 일관됩니다. 반면 단계는 테스트에 포함됩니다. 사용하는 단계가 아니라 태그로 테스트 세트를 식별합니다.

아, 그리고 저는 실제로 "건너뛰기" 테스트가 아니었습니다. 테스트 실행을 피하기 위해 callback( null, 'pending' )을 사용하고 있었습니다. 새로운 '건너뛰기' 기능은 탁월한 솔루션입니다.

@charlierudolph , 나는 다른 해결책을 생각하고있었습니다 ...
World 개체를 구성할 때 테스트에 사용된 Scenario 개체에 대한 참조를 제공합니다.

World는 모든 콜백에 대해 "this"로 사용할 수 있으므로 V2와 완전한 패리티를 달성합니다(AfterAll 콜백에 결과가 제공된 경우).

@leggebroten

1. 관찰자 패턴이 오이의 디자인 목표라는 말을 들어본 적이 없습니다.
2. 시나리오 이름도 단일 캐릭터 변경으로 변경되기 때문에 취약합니다. 관련 없는 작업을 수행할 때 파일/줄 번호 나누기에 동의합니다. 테스트를 실행하지 않고 결과를 보고할 때 사용하자고 제안한 것이므로 취약한 부분은 그다지 부정적인 영향을 미치지 않습니다.
3. Using Steps to alter State violates DRY 이해가 되지 않습니다. 태그는 기능 선택에 사용되며 단계는 설정/액션/기대에 사용됩니다. 이것들은 다른 목적입니다. 태그가 지정된 후크가 있는 설정을 위해 태그를 사용하는 것에 대한 지원은 최소한이지만 복잡성을 처리하도록 구축되지 않았습니다.
4. 나는 보고를 위해 포맷터 출력을 파싱하는 것을 제안했을 뿐입니다. 테스트 실행에 관여해서는 안됩니다.
5. Adding Steps (a semantic part of the test) to alter the Feature's state is counter to intent of Cucumber of isolating test writer 나도 이해가 안 된다. 단계를 사용하여 작업을 수행하고 상태를 설정할 수 없다면 테스트를 어떻게 실행하고 있습니까?
6. Tags are metadata ABOUT the test, it is semantically consistent to use them to alter the state in which the test will run . 일관성이 있다는 점에 동의하지 않습니다. 나에게 태그는 테스트를 식별하기 위한 것입니다. 최소한의 상태 변경은 지원하지만 매개변수가 있는 복잡한 상태 변경은 지원하지 않습니다.

시스템에 더 이상 시나리오 개체가 없습니다. v2와의 패리티가 목표가 되어서는 안 된다고 생각합니다. 이 대화가 나왔고 다른 솔루션을 찾고 있어서 기쁩니다. 하지만 사용자가 오이의 인터페이스가 아니라 구현에 훨씬 더 의존하게 만들었다고 생각하기 때문에 이전으로 돌아가고 싶지 않습니다.

@charlierudolph ,

시간을 내어 이 문제를 논의해 주셔서 감사합니다. Cucumber-js를 제공하기 위해 수행한 작업에 진심으로 감사드립니다. 그러나 그대로 V3로 업그레이드할 수 없습니다.

나는 전투적일 생각이 없다. 걱정이 되기도 하고 제 답변에 나올 수도 있습니다.

이전 버전의 문서화된 이벤트 인터페이스만을 사용하여 운영 체제/버전, 브라우저/버전, 데스크탑/ 모바일 및 Optimizely A/B 테스트.

단계를 사용할 수 없습니다. 너무 늦었어 장치 유형, OS/버전 및 브라우저/버전은 테스트가 시작되기 전에 결정되어야 하며 그렇지 않으면 모든 시나리오에 "OS 설정" 단계와 "브라우저 설정" 단계가 있어야 합니다. 이것은 Cucumber의 목표와 직접적으로 충돌합니다.

또는 앞에서 언급했듯이 시나리오 정보(기능 URI, 이름, 행 및 태그)를 World 생성자에 제공할 수 있습니다. 이것은 의미적으로 World 객체의 의도와 일치하며 캡슐화 및 확장이 더 간단합니다. 이것은 대부분의 이벤트 핸들러를 제거할 뿐만 아니라 핸들러의 "this"가 World 개체이기 때문에 관찰자 패턴과 일치하는 상태입니다.

1. 나는 Observer Pattern이 Cucumber의 디자인 목표라고 말하지 않았습니다. Hooks와 Events는 Observer이고, 따라서 작업을 수행하는 데 필요한 상태를 제공받아야 합니다. 이 패턴을 사용하면 호출자의 구현과 이벤트 핸들러를 분리할 수 있습니다.

2. 나는 실제 이름에 의존하지 않습니다. 그러나 그것들은 고유하기 때문에 Browserstack에서 연관된 사용자 의미 세션 이름을 구축하는 수단입니다.

3. Before 동안 태그 세트에 액세스할 수 있어 테스트를 수정(단계 추가)하지 않고도 상태 변경(예: Optimizely URL 매개변수 설정)을 위한 재사용 가능한 구성을 빌드할 수 있었습니다. 이것은 내가 실행하고 싶은 테스트(태그)와 설정 사이에 1-1 상관관계가 있음을 의미했습니다. 마른.

4. 개발자가 구현에 의존하고 있다는 우려를 표명했지만 필요한 관찰자 상태를 제거하는 솔루션은 개발자를 다른 구현(파일 형식)에 의존하게 만드는 것입니까? 사용자가 State 속성에 액세스하는 것보다 더 지루하고 느리고 오류가 발생하기 쉬운 작업 구문 분석을 수행하도록 하는 것이 어떻게 더 나을 수 있습니까?

5. 분명히 단계는 테스트 상태를 설정하고 있습니다. 그러나 Cucumber의 디자인 목표 중 하나는 단계를 작성하는 사람이 기본 구현에서 격리되어야 한다는 것입니다. EG는 기본 세부 사항에 얽매이지 않고 의미론적 동작을 테스트합니다. 쿼리 매개변수를 변경하는 단계를 추가하고 장치/브라우저/OS를 정의하는 것은 이 목표에 어긋나는 것 같습니다.

6. 당신을 위해 태그는 테스트 식별에 관한 것입니다. 그러나 Cucumber Wiki 는 태그를 많이 사용합니다.

7. 구성 및 그룹화
8. 필터(명령줄을 통해 세트 실행)
9. 관련 문서에 대한 링크(예: Optimizely 플래그)
10. 프로세스에서 기능이 어디에 있는지 나타냅니다.

Before 콜백 동안 태그에 액세스하면 테스트를 실행하는 데 사용되는 브라우저 구성을 기반으로 적절한 상태를 확인할 수 있습니다. 태그를 사용하면 선언적입니다. 단계를 사용하면 의도가 난독화됩니다.

이전 버전의 이벤트 처리기 호출 및 매개변수는 WERE 인터페이스입니다. 개발자가 코드를 구현과 결합하여 누출되는 경우 읽기 전용 "시나리오" 프록시를 이벤트 핸들러에 전달합니다.

@charlierudolph 답변 감사합니다

시나리오 이름도 단일 캐릭터 변경으로 변경되기 때문에 취약합니다. 관련 없는 작업을 수행할 때 파일/줄 번호 나누기에 동의합니다. 테스트를 실행하지 않고 결과를 보고할 때 사용하자고 제안한 것이므로 취약한 부분은 그다지 부정적인 영향을 미치지 않습니다.

사실, 시나리오 이름도 취약하지만 파일과 줄로 참조하는 것보다 시나리오를 참조하는 데 훨씬 덜 취약합니다. 우리는 매일 로깅에서 시나리오 이름을 사용하여 실행 실패를 분석하고 무엇이 잘못되었는지 확인합니다. 로깅에 파일과 줄 번호만 표시되면 시나리오를 역추적하기에는 너무 많은 오버헤드가 발생합니다. 게다가 누군가가 기능 파일을 변경하거나 시나리오를 그 동안 다른 곳으로 옮기면 상황이 훨씬 더 복잡해집니다.

로깅에 파일과 줄 번호만 표시되면 시나리오를 역추적하기에는 너무 많은 오버헤드가 발생합니다.

어떻게 더 오버 헤드가 있습니까? 파일과 줄 번호를 알고 바로 갈 수 있습니다. 시나리오 이름이 있는 경우 해당 문자열을 검색하여 해당 파일 및 행으로 이동해야 합니다.

어떻게 더 오버 헤드가 있습니까? 파일과 줄 번호를 알고 바로 갈 수 있습니다. 시나리오 이름이 있는 경우 해당 문자열을 검색하여 해당 파일 및 행으로 이동해야 합니다.

내가 말했듯이, 그 사이에 기능 파일이 변경되고 시나리오가 더 이상 그 줄에 위치하지 않는다면. 특히 이전 테스트 실행(예: 1주 전)의 로그를 볼 때. 이 경우 git을 통해 주어진 시간에 해당 라인에 어떤 시나리오가 있었는지 확인해야 합니다.

FWIW, 오이-루비에는 "쉬운 것은 쉬워야 하고, 어려운 것은 가능해야 한다"는 원칙을 충족하는 두 가지 확장점이 있으며 이러한 사용 사례에 도움이 될 수 있는 아이디어일 수 있습니다.

우선 RunningTestCase 의 인스턴스를 각 후크에 전달합니다. 이것은 Gherkin 소스(시나리오/개요/태그 등)에 대한 모든 정보와 시나리오의 현재 결과 상태를 포함하는 변경 불가능한 값 개체입니다. 변경할 수 없다는 것은 사용자가 우리에게 무언가를 시도하고 변경할 수 있는 경우를 고려하지 않아도 된다는 것을 의미하지만 마찬가지로 현재 플레이 상태에 대한 투명성을 제공합니다.

둘째, 필터 가

HTH

필터에 대한 링크 뒤에 있는 문서가 끔찍하다는 것을 방금 깨달았습니다! 죄송합니다. 지금 고칠 시간은 없지만 여기에 몇 가지 예가 더 있습니다. http://www.rubydoc.info/github/cucumber/cucumber-ruby/Cucumber/Filters

안녕하세요 @charlierudolph ,

이 대화에 대한 후속 조치를 취한 지 얼마 되지 않아 죄송합니다. 귀하의 진술에 대해 자세히 설명해 주시겠습니까?

"실행 중인 시나리오에 해당 유형의 프로필이 포함됩니까? 세계와 상호 작용하는 프로필 유형을 시나리오에 저장한 다음 저장된 프로필을 제거하라는 단일 태그를 가질 수 있습니까?"

팔로우하고 있는지 잘 모르겠습니다.

그리고 이전 테스트 결과 없이 동일한 솔루션을 얻을 수 있는 다른 방법이 있을 수 있음을 이해합니다. 그러나 이 대화에서 내가 지금까지 본 것은 모든 대안이 필요 이상으로 복잡해 보인다는 것입니다. 이전 테스트 결과에는 실행하려는 시나리오에 대한 많은 설명 데이터가 있었고 이것이 "매개변수화된" 후크를 갖는 유일한 방법이었습니다. 내가 보고 시도한 각도기는 현재 시나리오 줄 번호에서 기능 실행을 지원하지 않습니다. 그래서 새로운 testCase 결과는 상태 외에는 그다지 유용하다고 생각하지 않습니다.

PickleFilter와 함께 getTestCasesFromFileSystem을 사용할 때 반환된 결과와 testCase가 일치하는지 확인하고 싶습니다. 나는 이것을 샤드로 각도기에 전달할 태그로 시나리오 필터링을 지원하는 몇 가지 흥미로운 병렬 작업을 수행하는 데 사용했습니다. 그 결과에서 반환된 정보는 훨씬 더 유용하며 testCase 결과에 있으면 매우 유용할 것이라고 생각합니다.

PickFilter의 결과 예:

{ pickle: 
     { tags: [Object],
       name: 'Github test with page object',
       language: 'en',
       locations: [Object],
       steps: [Object] },
    uri: 'test/features/examples/github-example.feature' }

정확히 일치해야 한다고 말하지는 않지만 이 결과에서 나와 여기 다른 사람들이 혜택을 볼 수 있음을 많이 봅니다.

내 예에서 흥미롭다면 여기에서 사용하고 있습니다. https://github.com/gd46/dibellag-automation-framework/blob/master/configuration.js#L91

@charlierudolph testCase 가 설정되는 곳인가요?

https://github.com/cucumber/cucumber-js/blob/fbff6b0fae54d2e341ee247addc60a9f05753f1d/src/formatter/helpers/event_data_collector.js#L22

내가 말할 수있는 것은 testCase를 따라 피클에 대한 참조가 있습니다. 그렇다면 피클 결과에서 testCase 결과로 몇 비트를 더 반환하지 않는 이유는 무엇입니까?

@gd46 좋습니다. sourceLocation을 대체하는 후크에 전달되는 개체에 pickle 를 추가하겠습니다. 이 기능에서 업데이트해야 합니다. https://github.com/cucumber/cucumber-js/blob/master/src/runtime/test_case_runner.js#L153

안녕하세요 @charlierudolph , 방금 귀하의 의견을 보았습니다. 그것은 좋을 것입니다! 나는 이것을 곧 살펴보려고 노력할 것이다. 기꺼이 기여하겠습니다.

@charlierudolph 변경 사항을 명확히 하고 싶었습니다. sourceLocation과 같이 pickle에 줄 번호가 없는 uri가 직접 포함되어 있다는 차이점에 대해 괜찮습니까? 그리고 줄 번호로 uri를 사용하려는 사람은 피클 개체에서 반환된 줄 번호를 사용할 수 있습니까? 나는 이것에 문제가 없다고 확인하고 싶었습니다.

소스 위치 개체를 제거하는 대신 그대로 두고 피클 개체를 추가해 보겠습니다.

좋아, 그것은 나에게도 효과적입니다. 그래서 오이에 기여하는 것이 처음이고 구조를 이해하려고 노력하고 있습니다.

업데이트해야 하는 행을 지적했듯이 sourceLocation 옆에 다음과 같은 것을 추가하면 됩니다.

pickle: this.testCase.pickle

그런 다음 후크에서 소비하려는 사람은 다음과 같이 액세스할 수 있습니다.

testCase.pickle.tags
testCase.pickle.name
etc. 

업데이트를 했지만 모든 관련 테스트를 업데이트하는 방법을 100% 확신할 수 없습니다. 안내를 좀 해 주시겠습니까?

포크를 로컬 프로젝트 중 하나에 대한 변경 사항과 연결하여 변경 사항을 테스트할 수 있었습니다. 전체 testCase 결과는 다음과 같습니다.

{
  "sourceLocation": {
    "uri": "test\/features\/examples\/example.feature",
    "line": 4
  },
  "pickle": {
    "tags": [
      {
        "name": "@example",
        "location": {
          "line": 3,
          "column": 3
        }
      }
    ],
    "name": "Custom Transform should take belly and capitalize it",
    "language": "en",
    "locations": [
      {
        "line": 4,
        "column": 3
      }
    ],
    "steps": [
      {
        "text": "I have cucumbers in my belly",
        "arguments": [

        ],
        "locations": [
          {
            "line": 5,
            "column": 10
          }
        ]
      }
    ]
  },
  "result": {
    "duration": 7,
    "status": "passed"
  }
}

더 많은 테스트를 수행한 후 test_case_runner에서 액세스할 수 있는 시점에 pickle에 uri가 포함되어 있지 않다는 것을 알았습니다. 따라서 소스 위치를 그대로 유지하는 것이 좋다고 생각합니다.

이것은 PickleFilter가 피클을 다음과 같이 반환하는 것입니다.

{
    "pickle": {
      "tags": [
        {
          "name": "@example",
          "location": {
            "line": 3,
            "column": 3
          }
        }
      ],
      "name": "Custom Transform should take belly and capitalize it",
      "language": "en",
      "locations": [
        {
          "line": 4,
          "column": 3
        }
      ],
      "steps": [
        {
          "text": "I have cucumbers in my belly",
          "arguments": [

          ],
          "locations": [
            {
              "line": 5,
              "column": 10
            }
          ]
        }
      ]
    },
    "uri": "test\/features\/examples\/example.feature"
  }

따라서 모든 것은 uri가 포함되지 않은 동일한 빼기 피클이 될 것입니다.

지금까지의 변경 사항을 강조하기 위해 PR을 열었습니다. 여전히 테스트를 업데이트해야 합니다.

테스트 업데이트 작업. 내 로컬 Java 버전을 변경하기 위해 이 설정을 했고 일부 기능 테스트를 실행할 수 없었던 이유를 깨달았습니다.

이 스레드는 닫힌 후 최근 활동이 없었기 때문에 자동으로 잠겼습니다. 관련 버그에 대한 새 문제를 여십시오.