I am writing Behat tests for a project that uses the Group module. I'm a Behat newbie and wondered if anyone has experience with/or written any contexts for Group. If there is something out there, perhaps a group.behat.inc could be added so Drupal Extension could pick it up.

Issue fork group-2877493

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

boinkster created an issue. See original summary.

jonathanshaw’s picture

Did you manage to get anywhere with this?

jnicola’s picture

I've written a bunch in a feature context file. I was debating inquriing about how to go about sharing them back on this module.

Here's an example of a test I've written:

Scenario: Authenticated users with group admin role can perform necessary functions
    Given I am logged in as a user with the "authenticated" role
    When I am viewing a group of type "ohsu_default_group" with the title "This is a test 84C"
    And I am a member of the current group with the role 'admin'
    Then I view the path 'edit' relative to my current group
    Then I should see the text 'Edit This is a test 84C'

If anyone can provide insight on how to share these back as a patch for this module, I'd be happy to proceed with this.

jnicola’s picture

I can't upload a PHP file, so here's a .txt version of exactly what I have written for testing.

If you work with this and modify it into a patch here for later integration, please be sure to provide authorship with the patch.

jonathanshaw’s picture

Very nice, thankyou

jnicola’s picture

Ah-ha! I figured out how to include subcontexts.

You will need to follow these directions to let behat know to search for everything:
https://behat-drupal-extension.readthedocs.io/en/3.1/subcontexts.html

jnicola’s picture

FileSize
0 bytes

Okay, ANOTHER update!

Turns out the previous one I wrote was for the old version of Behat that allowed subcontext. The new version (3 and beyond) does not allow this, however there is a way within the Drupal extension. Utilizing this, everything works presuming you follow the directions in the article linked.

I disabled display of the previous patch and went no interdiff since it was just simply not right.
I disabled display of the text file since I have since updated the code for groups to load them by their alias as well.

This is working fine for me locally!

jnicola’s picture

FileSize
4.33 KB

Updating with a patch that actually has something in it, heh. Hiding previous one since I was a dummy and committed a blank file :)

jnicola’s picture

FileSize
4.61 KB

Okay, final commit, that actuall works. Sorry to be so sloppy, I'm blaming it on this being a Monday :)

Example code did not include necessary __construct() as declared in the interface. Updated to properly include. Works fine now!

Be sure to properly update your behat.yml file (or whatever yml config you are loading for behat) to include the subcontexts paths.

jnicola’s picture

Status: Active » Needs review
jnicola’s picture

Updated patch with a simple step to load the current group.

jnicola’s picture

Added two new chunks of functionality:

@Given There is a group of type :arg1 with the title :arg2
@Then I load the group with title :title

This will let you create multiple groups and navigate between them as needed.

Status: Needs review » Needs work

The last submitted patch, 12: behat-testing-context-2877493-12.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

jnicola’s picture

Added new behat feature context: User with name :user_name is a member of group with title :group_title

rjg’s picture

Is this working for anyone on the latest release (rc4)?

I'm using a custom behat context which mirrors the patch here very closely. When I create a node and add it to a group, the group member is getting a 403. It works fine locally outside of behat, and it also works when I set my cache bins to null (ex. `$settings['cache']['bins']['...'] = 'cache.backend.null';`), but fails with a 403 on visiting the node directly when cache is enabled. We have custom node grants/access records based on a custom field on that node which work fine (nothing gives permission denied, just allowed or neutral), and have in previous versions of group. I can't figure out why a group member with the permission `Entity: View content entities`is getting a 403 in only behat, after upgrading from rc2 to rc4.

Jax’s picture

Sorry to post this here since it is actually not related to the issue but is related to comment #15. We're also having issues with the group cache when doing manipulations in Behat. When updating a user within Behat (Drupal api_driver) the cache tag group_content_list:plugin:group_membership:entity:xyz doesn't get cleared...

mikran’s picture

This now ends up in error

Type error: Argument 2 passed to Drupal\Driver\DrupalDriver::entityDelete() must be an instance of stdClass, instance of Drupal\group\Entity\Group given, called in web/modules/contrib/group/group.behat.inc on line 229 (Behat\Testwork\Call\Exception\FatalThrowableError)

Here is updated patch that fixes that error.

mikran’s picture

Status: Needs work » Needs review
FileSize
7.71 KB
7.33 KB

Bunch of code style fixes. This patch does not do any functional changes.

What else is needed before this is ready? And given that this type of sub contexts are not widely used will group accept this?

jnicola’s picture

What do you mean by: "this type of sub contexts are not widely used"

Is there some alternative that is more common? Or is this just not something many modules include or have.

It would seem to me that this is the standard way to include important things for Behat testing, which given how often it's presented on at Drupalcon and other Drupal functions I'm sure the community is hot to trot for!

mikran’s picture

With that I was referring to the documentation page, it starts with

Although not yet a wide-spread practice, the Drupal Extension to Behat and Mink makes it easy for maintainers to include custom step definitions in their contributed projects.

jnicola’s picture

Ah, gotcha!

Well it would seem to me the only way for it to become widespread practice is for it to be implemented!

Let's get this accepted!

I unfortunately can't say that this works for my entity. I know it was working great and what we've got is built upon the initial work I did here, but bur implementation of group is rather customized and we've got a lot of additional group testing steps in our file. That resulted in us having to diverge from this patch.

mikran’s picture

fix typo & loading a group now sets that group to be the current group

Peter Törnstrand’s picture

I'm trying this out but I ran into some problems using @Then I am a member of the current group with the role :group_role.

The user is not added to the group with the specified role, tracked back to Drupal\group\Entity\Group::addContent() and $violations = $group_content->validate();. The error I'm getting is This entity (group: 50) cannot be referenced.

Not sure why it's not validating.

Peter Törnstrand’s picture

Sorry, turns out this was not an error but a permissions problem specific for my setup.

Peter Törnstrand’s picture

Here is a patch that fixes human readable role name to machine name and adds @Given I am a member of the group :title with the role :group_role.

shelane’s picture

I was using patch 25 as a module for updates I'm making to the group drush commands. I found that using $group->getEntityTypeId(); on line 168 resulted in "group" but the actual machine name of the group type needs to be returned. It works if changed to $group->bundle(); which I have changed in this patch.

jnicola’s picture

Component: Group (group) » Code

Well for fun tonight I spent some time trying to extrapolate some of the group work we've done into a group submodule (gbehat) which in turn contains all of the behat contexts.

It seemed like it was working as I was seeing errors, and then I chased down the errors, and of course now behat doesn't want to see any of what I've done.

If anyone has any ideas or suggestions on how we could get this all functioning in a submodule, get at me. We've got some pretty rad stuff for groups I'd like to share.

Specifically, much like there is the UserManager in behat with Drupal, we've got an equivelant for GroupManager that allows tracking multiple groups, moving between them, creating them with a table of values, etc etc.

It's some pretty slick stuff, but I'm at the end of my behat knowledge on trying to make it work. Feel free to see the fork I opened up on this!

Nixou’s picture

Thanks a lot for this feature, it really helps.

I just had a problem with a service that do not exists (I think it has been renamed in Drupal 8.8).

Patch provided fix this problem.