search

Gizra / og

https://www.drupal.org/project/og
92 stars 133 forks source link

Add support for Behat #528

Open MPParsley opened 5 years ago

MPParsley commented 5 years ago

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 https://github.com/jhedstrom/drupalextension/pull/300. This could provide a way forward too.

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

MPParsley commented 5 years ago

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

zerolab commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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:

It uses a trait called OgTrait:

You can see in here typical steps like:

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 commented 5 years ago

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 commented 5 years ago

Is there an advantage to this over functional testing?

pfrenssen commented 5 years ago

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 commented 5 years ago

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 :thinking:

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 :thinking:

amitaibu commented 5 years ago

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.