Cucumber-js: 기능 후크 및 해킹 전/후

연속된 기능에 동일한 태그가 있는 경우 After를 호출하지 않습니다.

이해가 안 돼요. 이것에 대해 더 자세히 알려주실 수 있습니까? 존재 여부에 관계없이 태그와 관련된 After 후크를 생성할 수 있습니다. 해당 해결 방법이 제공된 이후 태그 구문이 변경되었습니다.

태그가 지정된 기능이 빌드의 마지막 테스트인 경우 After를 호출하지 않습니다.

이번에도 이해가 잘 안가서 설명좀 부탁드립니다. After 후크를 사용할 수 있어야 하지만 이것이 마지막 후크인지 여부에 대한 컨텍스트를 잃게 됩니다. 이상적으로는 여기서 분해를 수행할 필요가 없습니다.

또한 당신은 낙담하는 시나리오를 연결하려고 노력하고 있습니다. 다음 중 하나를 제안합니다.

• 시나리오 연결 끊기
• 다양한 지원 파일을 로드하는 오이-js를 여러 번 실행하고 BeforeAll/AfterAll을 사용합니다.

명확히 하자면, 내가 언급하는 해결 방법은 다음과 같습니다.

this.Before({ tags: ['<strong i="6">@featurehook</strong>'] }, function () {
  // log user in (if needed)
})

this.Before({ tags: ['~<strong i="7">@featurehook</strong>'] }, function () {
  // log user out (if needed)
})

몇 가지 기능을 고려하십시오.

<strong i="11">@featurehook</strong>
Feature: feature 1
   Scenario: scenario 1

<strong i="12">@featurehook</strong>
Feature: feature 2
   Scenario: scenario 2

Feature: feature 3
   Scenario: scenario 3

<strong i="13">@featurehook</strong>
Feature: feature 4
   Scenario: scenario 4

위의 순서로 실행하면 기능 1과 기능 2 사이에 분해가 발생하지 않습니다. 기능 4 이후에도 분해가 발생하지 않습니다. 왜냐하면 다른 테스트 일치가 없기 때문입니다 ~ @featurehook (이것은 다음으로 고칠 수 있습니다. 결국).

저는 시나리오를 연결하려고 하지 않습니다. 저에게는 격리와 성능 간의 균형을 자유롭게 결정할 수 있습니다.

다양한 구성으로 테스트 SMTP 서버를 설정하는 테스트의 예를 살펴보겠습니다.

<strong i="20">@smtpConfig1</strong>
Feature: ....

<strong i="21">@smtpConfig2</strong>
Feature: ....

시나리오를 분해하지 않음으로써 시나리오 간에 부작용이 있을 수 있지만 이 경우 순도와 성능 사이의 절충이 가치가 있을 수 있습니다.

죄송하지만 이것은 지원되어야 한다고 생각하지 않습니다. 대부분의 경우를 다루는 단일 시나리오와 모든 시나리오에서 상태를 공유하는 기능이 있습니다. @featurehook이 있는 마지막 주석의 예는 어쨌든 BeforeFeature/AfterFeature를 사용하여 해결되지 않습니다.

BeforeFeature/AfterFeature 후크의 경우 +1
테스트 격리와 성능의 균형을 유지해야 한다는 데 동의합니다. 현재 프레임워크가 구축된 방식은 반복되는 배경 단계를 제외하고 단일 기능으로 시나리오를 연결하는 것이 거의 없습니다. 어떤 경우에는 배경 단계가 반복되는 것을 원하지 않을 수 있습니다. 오히려 기능 시작 시 한 번만 발생하고 모든 시나리오가 완료된 후에만 삭제되도록 할 수 있습니다.

항상 느리고 작업하기 힘든 Browserstack과 같은 서비스를 사용하기 때문에(Saucelabs와 같은 다른 원격 서버 공급자도 마찬가지입니다) 일반적으로 BeforeFeature 및 AfterFeature 이벤트 핸들러를 사용하여 기능 파일당 셀레늄 세션 및 분해를 설정합니다.

따라서 내 파일에 언급된 해당 기능과 관련된 시나리오가 함께 실행되고 각 시나리오의 게시를 새로 시작하기 위해 브라우저 화면을 새로 고치고 테스트를 위해 앱 상태를 새로 고칩니다. 따라서 어떤 면에서는 격리되고 테스트 성능에도 영향을 미치지 않습니다.

이는 위에서 제안한 바와 같이 기능 파일별로 오이js를 실행하는 것보다 Before/After 기능 후크를 다시 사용하도록 하는 경우로 간주되어야 합니다.

BeforeFeature/AfterFeature 후크는 e2e/uat/bdd/call-it-whatever-you-want 오이가 만들어지는 테스트에 필수적입니다.

Cucumber의 주요 "경쟁자"는 해킹 없이 이를 지원합니다(예: JBehave, RobotFramework). 이는 프레임워크의 적절한 기능입니다.

이 문제는 확실히 Cucumber 사용에 대한 차단입니다.

안녕하세요... 이와 관련된 문제에 직면해 있습니다. 제 경우에는 태그가 지정된 Before 및 After 후크를 사용하여 UI를 테스트하는 데 사용할 데이터를 생성/삭제합니다. Before 후크에서 API 끝점을 누르고 데이터를 생성하고 After 후크에서 다른 API 끝점을 눌러 삭제합니다(생성 응답에서 반환된 개체의 ID를 저장한 다음 해당 ID로 삭제 페이로드를 빌드합니다. )

문제는 해당 데이터를 사용하고 후크를 트리거하는 시나리오가 마지막으로 실행될 때 후크가 트리거되지 않는다는 것입니다...

이 문제를 해결할 수 있는 방법이 있나요??

감사 해요

기능 전후에 +1.
우리의 사용 사례는 다음과 같습니다. 다른 브라우저에는 나타나지 않는 특정 브라우저의 버그를 찾습니다.

다음과 같이 기능에 태그를 지정하려고 합니다.

@ie-8-only
Business Need: IE8 should have limited functionality, but what is displayed, should be displayed correctly

@no-access @ssl-insecurity <strong i="8">@security</strong> @BUG-1876
Scenario: No access
   Given I am on the home page
   When I see that my browser is not supported
   Then I should not be able to access the core site functionality

@formatting-issue <strong i="9">@bugs</strong> @BUG-1210
Scenario: The menu should not be formatted like a staircase
   For the users to be able to navigate to the about us / contact us area of the site, the site navigation should be active
   Given I am on the home page
   When I see the menu
   Then it should be displayed in a line

이렇게 하면 브라우저를 닫고 BeforeFeature 후크에서 IE를 열 수 있으며 AfterFeature 후크에서 나머지 제품군에 사용 중인 브라우저를 다시 열 수 있습니다. 모든 시나리오에 대해 브라우저를 닫았다가 다시 여는 데 많은 시간이 걸리므로 사용하기에 좋은 기능입니다.

메모:
나는 세계 객체를 포함하는 대안이 있다는 것을 알고 있습니다(현재 브라우저를 거기에 설정하고 브라우저가 이들에 대한 beforeAll Hook에서 필요한 것이 아닌 경우에만 닫음). 이미 후크에서 완료되거나 Selenium은 절반의 시간 동안 히시 핏을 던질 것이라고 결정합니다.

이 기능이 유용한 또 다른 예인 BeforeFeature Hook에서 기능에 대한 추가 설명으로 기능에 텍스트를 첨부하려는 경우가 있습니다.

특정 유형의 테스트에서는 기능 후크 전/후가 유용할 것이라고 생각합니다. 예를 들어 .NET용 Cucumber 라이브러리인 Specflow에는 다음이 구현되어 있습니다.
https://specflow.org/documentation/Hooks/

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