EntityResource: Provide comprehensive test coverage for Workflow entity

ModerationState entity doesn't exist anymore.

Thanks for updating this!

Let's add this test coverage only to 8.4.x, for the same reason as #2843770-11: EntityResource: Provide comprehensive test coverage for ResponsiveImageStyle entity:

Let's get this only committed to 8.4.x then. Reuploading #5, but only testing against 8.4.x, to not confuse committers.

Review:

1. +++ b/core/core.link_relation_types.yml
   @@ -3,6 +3,12 @@
   +add-state-form:
   +  uri: https://drupal.org/link-relations/add-state-form
   +  description: A form where a state can be created.
   +add-transition-form:
   +  uri: https://drupal.org/link-relations/add-transition-form
   +  description: A form where a transition can be created.
   

   The Workflow module is experimental.

   Therefore these belong in core/modules/workflows/workflows.link_relation_types.yml.

2. +++ b/core/core.link_relation_types.yml
   --- /dev/null
   +++ b/core/modules/hal/tests/src/Functional/EntityResource/Workflow/WorkflowHalJsonAnonTest.php
   

   The Workflow module is experimental.

   Therefore these belong in core/modules/workflows/tests/src/Functional/Rest.

So: move a few things, then this is ready :) Thanks!

Thanks!

+++ b/core/modules/workflows/tests/src/Functional/Hal/WorkflowHalJsonAnonTest.php
@@ -0,0 +1,30 @@
+ * @group hal

+++ b/core/modules/workflows/tests/src/Functional/Hal/WorkflowHalJsonBasicAuthTest.php
@@ -0,0 +1,24 @@
+ * @group hal

+++ b/core/modules/workflows/tests/src/Functional/Hal/WorkflowHalJsonCookieTest.php
@@ -0,0 +1,19 @@
+ * @group hal

+++ b/core/modules/workflows/tests/src/Functional/Rest/WorkflowJsonAnonTest.php
@@ -0,0 +1,24 @@
+ * @group rest

+++ b/core/modules/workflows/tests/src/Functional/Rest/WorkflowJsonBasicAuthTest.php
@@ -0,0 +1,34 @@
+ * @group rest

+++ b/core/modules/workflows/tests/src/Functional/Rest/WorkflowJsonCookieTest.php
@@ -0,0 +1,29 @@
+ * @group rest

Are these correct after the move?

@larowlan They're correct (they're consistent with others), but they actually should also have @group workflows is what you're saying. But in Drupal core, we apparently don't do multiple @groups anymore. There's no clear rules for this.

So, leaving it to you to decide what makes sense to you: either keep it as-is, or change all of those to @group workflows.

We have test workflow type plugins we can use, so we aren't coupling workflows tests to content_moderation. Using them makes sense to me in this context.

Oh, even better!

Actually, this is not just about test coverage. These functional tests are designed to mimic what actual developers in the real world do, what they expect to work, and guarantees that a given mistake results in a given helpful error message.

Because of that, I think I actually would prefer to use the "real" thing.

I don't feel strongly about this though.

We'd want any workflow types someone might implement to also work and be covered. It's closer to testing the abstraction vs an implementation, but I don't feel that strongly about it either.

Content moderation is probably on the extreme side of how much is wrapped around the specific workflow type, but you could argue it should introduce its own test for those edge cases, if they exist, and workflows should just be testing the abstraction and functionality it provides.

#18: Works for me :)

Back to RTBC. Still up to @larowlan to make a choice wrt #15.

This is actually a must-have for the Workflows module to reach beta-level stability, because this helps prevent BC breaks.

Added this to the "must-have" in the roadmap #2843494: WI: Workflows module roadmap.

#21: ❤️

Updating credit to include Wim who provided reviews and mentoring here.

Can we get a follow up to move the tests back into rest module when workflow module is stable as per #10?

Committed as 6002539 and pushed to 8.4.x. Thanks!

Gotta love those all numeric shas.

Can we get a follow up to move the tests back into rest module when workflow module is stable as per #10?

Hm, actually, isn't it better like this? I'd love to eventually move all this REST test coverage into the respective modules at some point I think.

(It means everything is self-contained — imagine each core module being exposed as a separate composer package.)

Roger that

I'd have been happy to open a follow-up if you disagreed — but if you agree, that's even better of course!