What is best practice for using BPOE?

[bartonhammond]

It seems to me, when using BPOE, that each Feature needs to have it's own pair or Context & POM. That keeps things organized, at least in my mind.

It also means there is duplicated code. I currently have 2 Features and both of my Contexts have "I am on the ?? page" and "I should see the ?? link". I want to make sure when confirming certain links are visible, that I'm testing with the correct POM.

That's all fine when testing Features/Scenarios. But I have to also run my tests w/ CrossBrowserTesting so we can verify all the pages perform correctly and look right. Rather then have our UI guy look through all the screen shots from multiple Features, I'd like to build one Feature that contains happy path solution. My problem is, if I separate all the Features/Contexts, I don't think I'll be able to make this happy path solution as I won't the appropriate Context.

Do you have a recommendation on how to address this? Also, do you have any example projects that are using BPOE that you would recommend? Yes - I've searched for them. I've not found one that is anything more then a simple example.

Thanks.

[DonCallisto]

Usually I split my context for "Subject --> Action", something like "User --> SignupContext, LoginContext, ResetPasswordContext" and so on. It could be the case where contexts has same steps: I don't mind as I build my suites as follows

default:
  suites:
    ui_alunno_import:
      paths:
        - '%paths.base%/Features/Alunno'
      contexts:
        - NuvolaBehat\Context\Ui\Alunno\ImportContext
        - NuvolaBehat\Context\Ui\Ata\ScegliAreaDiLavoroContext
        - NuvolaBehat\Context\Ui\Hook\UiHookContext
        - NuvolaBehat\Context\Ui\Utente\ImpersonaContext
        - NuvolaBehat\Context\Ui\Utente\LoginContext
      filters:
        tags: "@alunno_import && @ui" 

This way I use only Context that I really need.

Don't know if this can help you. Moreover I can't see how this problem could be related to this extension.

[jakzal]

The idea behind page objects it to encapsulate all page interactions and page details extraction in page objects. Your context files will only call page objects to perform an action, or ask a page object for some page details (like title, header, if something is present on the page etc).

This way you avoid duplication as all the gressy details are in one place (page objects). You still might have to call the same page object in a similar way from multiple contexts. These one liners are usually not a big deal.

Sometimes it's worth to reconsider how you group your steps around contexts. It's not easy thing to do in cucumber implementations in general, whether you use the PO extension or not.

[bartonhammond]

Thanks @jakzal & @DonCallisto - I appreciate your feedback - I'm not sure exactly how to address this but it's comforting to know it's not a problem specific w/ me.

[DonCallisto]

@bartonhammond Take a look at Sylius. I can't remember if they're using this extension - probably not - but the approach they follow to structure Features and Contexts is similar to what I've tried to explain with my snippet. Maybe you can find there some useful techniques.

Good luck!

[bartonhammond]

@DonCallisto Thank you very much! I can chew on this awhile.