Tests broke after an update to schemata, that changes the resulting definitions. Ultimately our tests shouldn't be dependent on other modules not making changes. We should refactor our tests such that they don't depend on schemata as rigidly.

Schemata is doing the same tests as we are to prove that the schema is built correctly. Thus there is no need for us to duplicate these efforts. We should instead assume that schemata will build the schema correctly, and be verifying that the correct data was returned by openapi. In particular we need to verify the the filtering feature works as intended and that a user can limit the documents based on entity type and bundle. Beyond that we don't need to track schema for anything that we aren't explicitly adding to the structure.

Comments

richgerdes created an issue.

richgerdes’s picture

richgerdes
he/him
Primary language English
Location New Jersey, USA
commented

Thinking more about this. I think there are two important things that we need to do with testing.

  1. We do what we are trying to do. Thats the goal right? Tests should validate that the keys being added actually exist. For example, the urls are valid, and that the entity types are valid.
  2. The module generates valid schema. This is a less straightforward objective. We can't determine the validity of our schema simply from drupal. We need to rely on an external project, such as nabbar/SwaggerValidator-PHP which will handle the validation for us.

Right now, our tests focus mostly on objective 1 above, but don't completely validate that the information is correct. This is mostly determined by the developer, when validating that the changes to the text expectations, is what they expected it to. Ultimately the expectations should be dropped, and we should focus on just the content of the returned document. Additionally, moving to use validation on the resulting schema, will enforce that we keep to expected versions, and follow spec correctly.