Add support for Behat

[MPParsley]

In order to write Behat test for Organic Groups, we'd need some "Gherkin" Drupal contexts for the custom entities that OG is providing (e.g. OgMembership, OgMembershipType, OgRole).

These contexts are really specific for Og and I wonder if we could provide them here, either as snippets/documentation or as real Context in the sourcecode?

On the other hand, there's work being done to allow the creation of custom entities (other than, node, user & term) in jhedstrom/drupalextension#300. This could provide a way forward too.

I'd be happy to get some intput in this.

[MPParsley]

@pfrenssen, do you happen to have some Behat context extensions of Drupal\DrupalExtension\Context\RawDrupalContext laying around?

[zerolab]

We used a context/trait inspired by https://github.com/ec-europa/joinup-dev/tree/develop/tests/src/ in our project a while ago. Hope it helps

[MPParsley]

Thanks for the input @zerolab! We're using similar classes but I didn't find any specific Drupal contexts for Organic Groups.

I'm looking for something like:

  Scenario: Chief editor can create news if he belongs to the group.
    Given group content:
      | title      |
      | Test group |
    When I am a member of the group "Test group" with the role "chief editor"
    Then I should be able to edit an "article" in the group "Test group"

[zerolab]

Ah, I see.

Here's our subcontext, OgTrait and behat feature - https://gist.github.com/zerolab/96ab2e3044fd3243a7094a90626d479e
Where a group is called a network. Hope it helps

[pfrenssen]

I like this idea! I am also involved with the Behat Drupal Extension project so I welcome this.

The Joinup project linked above is indeed a good source of inspiration. This project uses two group types: one is called "collections" and one called "solutions". Here are the subcontexts for both:

• https://github.com/ec-europa/joinup-dev/blob/develop/web/modules/custom/collection/collection.behat.inc
• https://github.com/ec-europa/joinup-dev/blob/develop/web/modules/custom/solution/solution.behat.inc

It uses a trait called OgTrait:

You can see in here typical steps like:

• @Given (the following ):bundle content belong to the corresponding solutions: - adding group content to a group.
• @Given (the user ):username should be the owner of the :solution solution - checks if a user is a group administrator.
• @Given (the following )solution user membership(s) - creates memberships within a group.
• @Then the :collection collection should have :number :membership_state member(s) - checks that a group has a certain number of memberships with certain states.
• @Then I am member of :labels collection(s) + @Then user :user_name is member of :labels collection(s) - checks membership of an individual user.

In Behat it is always important to allow users to write their own steps easily, so we should split off as much code as possible to a reusable trait.

We do not know the business language preferred by our users, so we can only provide steps like @Then the :group_name :group_type has :count member(s), but we can be pretty sure that anyone that follows BDD practices will not be using our definitions but wanting to write their own.

As you see in the examples from the Joinup project they use their own business language. They do not even have the word "group" anywhere, since their clients do not know we are using a Drupal module for this that is called "Organic Groups". For their clients the correct terminology is "collections" and "solutions".

We should avoid falling in the trap of using machine names of entity types and bundles, because this results in step definitions which violate the basic principles of BDD. We should do a lookup of the human readable bundle names and use these. And avoid the use of entity types entirely.

It would be bad to have a step definition reading Then I am a member of the "node" group of type "basic_page" with title "My Group" -> very likely clients are non-technical and do not know that their "Page" content type has a machine name basic_page and belongs to an entity type called node.

I think maybe the best approach would be to provide a trait and some example code that people can adapt to their use case. I followed this approach in https://github.com/drupaltest/behat-traits/ - this project provides reusable traits as the deliverable, but it also provides example Contexts which can be extended (or used directly, if a project has simple requirements).

So basically, I would go with a trait and an example context which we can use ourselves for testing that the Behat code works correctly, and can be used by developers as an example, or directly if they have simple requirements. Let's avoid using a subcontext for now.

[pfrenssen]

Seeing the comment from @zerolab above I think it is significant they also do not use the word "group" in their steps, in their business language a group is called a "network". This shows correct usage of BDD principles of using the client's business language in Behat scenarios.

I think this reinforces my idea that we should not try to provide step definitions that are supposed to work out-of-the-box (i.e. a subcontext). It won't be so useful, every project has their own terminology.

[amitaibu]

Is there an advantage to this over functional testing?

[pfrenssen]

Behat is not intended for testing, but it is a tool that describes the end user functionality of a project to the business that owns the project. It can be used as a very cheap way to test UIs, but that is a side effect :)

So we should not use it ourselves to test our functionality, but we can make it easy for people to use Behat to demonstrate the projects they build to the business stakeholders.

[pfrenssen]

Actually it wouldn't be a bad idea to provide Behat scenarios ourselves to demonstrate how to set up some typical scenarios using groups and group content 🤔

People have historically struggled a lot with OG's UI, so having some Behat scenarios that show it step by step could be very helpful for site builders 🤔

[amitaibu]

Ok, I thought the issue was about having the tests for OG using.

I used to be a big fan of Behat, but now days I feel it can be easily abused.

having some Behat scenarios that show it step by step could be very helpful for site builders

I personally think documentation would be better.