- π¨π¦Canada spiderman Halifax, NS
I've been thinking about this issue with Workflow the last few weeks as I watch @johnv struggle to fix a host of interlocking bugs across the 1.8 release. The project I'm working on most recently *does* have tests that exercise the Workflow behaviour that we rely on, but unfortunately they're not really applicable in a general sense (they encode client-specific node types and fields, etc). That being said, I am a big fan of `behat` and behaviour-driven testing, especially when there isn't a lot of test coverage to begin with. I'm all for unit tests and such, but it can often be hugely valuable to just start with a test like:
Feature: A node can move through workflow states
In order to publish my node
As a Workflow module user
I need to move a node through workflow statesScenario: I can create a node in an initial workflow state
... steps to create a node of a fixture type with a workflow attached ...Scenario: I can transition a node to another workflow state
... steps to create a node, save it, and then transition to next workflow state ...and build on it from there. This has the benefit of documenting the "happy path" use-cases of the module at the same time as catching regressions: if you do anything that interferes with creating a node and transitioning its workflow state, these 2 scenarios alone will catch it! Obviously a comprehensive set of unit tests will help identify *where* that failure arises, but at least it's a start.
Anyway, all of that to say: I've been doing a bunch of contrib maintenance work the last couple weeks, and am very keen to modernize the infrastructure for my various projects to leverage Gitlab CI to easily run the core tests as well as a basic suite of Behat tests. I'd be happy to collaborate on helping with a similar effort on Workflow module, if desired :)
- π³π±Netherlands johnv
I would love to receive some help with that.
As a part time developer, the D8, 9, 10,11 changes require a lot of effort to keep up avoiding technical debt...