Skip to content
Snippets Groups Projects

Add a test for the OpenAPI spec for `/api/layout/{entityTypeId}/{entityId}`.

3 unresolved threads

Closes #3472632

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Travis Carden
  • 45 $psr7_request = $http_message_factory
    46 ->createRequest($request);
    47
    48 try {
    49 $validator->validate($psr7_request);
    50 }
    51 catch (ValidationFailed $e) {
    52 self::fail($e->getMessage());
    53 }
    54
    55 self::assertTrue(TRUE, 'The request passes OpenAPI validation.');
    56 }
    57
    58 public static function providerValidRequest(): array {
    59 return [
    60 'Post empty component tree' => [
    • These came straight from the examples that were already in the openapi.yml. (It's a nice side benefit that we can ensure that our examples actually work this way, too.)

    • If they're coming from there, can we then … just literally parse those examples instead? :nerd: :cowboy:

      Now that would be a superb unit test:

      • iterate over all paths in openapi.yml
      • in a path, iterate over all methods
      • in a method, iterate over all examples
      • test that the example complies with the spec
    • Yeah, if you consider the effort warrantable, that would be awesome. Let's do that.

    • Please register or sign in to reply
  • 27 * @param array $files
    28 * The request files (`$_FILES`).
    29 * @param array $server
    30 * The server parameters (`$_SERVER`).
    31 * @param string $content
    32 * The raw body data.
    33 *
    34 * @see \Symfony\Component\HttpFoundation\Request::create()
    35 *
    36 * @dataProvider providerValidRequest
    37 */
    38 public function testValidRequest(string $method, array $parameters, array $cookies, array $files, array $server, string $content): void {
    39 $validator_builder = self::getConfiguredValidatorBuilder();
    40 $validator = $validator_builder->getRequestValidator();
    41
    42 $request = Request::create('api/preview/node/1', $method, $parameters, $cookies, $files, $server, $content);
  • 69 'nodeType' => 'root',
    70 'name' => 'root',
    71 'children' => [],
    72 ],
    73 'model' => [],
    74 ], JSON_THROW_ON_ERROR),
    75 ],
    76 'Post component tree with single component' => [
    77 'method' => Request::METHOD_POST,
    78 'parameters' => [],
    79 'cookies' => [],
    80 'files' => [],
    81 'server' => ['CONTENT_TYPE' => 'application/json'],
    82 'content' => json_encode([
    83 'layout' => [
    84 'uuid' => 'root',
    • Comment on lines +82 to +84

      :thinking: Wouldn't using the PHP heredoc syntax be nicer, because it'd allow you to use actual JSON blobs, that you can copy/paste into the browser, curl etc too?

      IOW: that'd make it much simpler to add new test cases :nerd:

    • Ah, yes. If our goal is to make it easy for JS developers, that's easy to do.

    • Please register or sign in to reply
  • My #1 concern with this test currently is that it's too server-side-centric.

    The goal is that both front-end developers and back-end developers can easily update this.

    There are two mitigations I see/proposed:

    1. consuming the examples in /openapi.yml ⇒ people changing only an example in /openapi.yml without touching a line of PHP get helpful feedback too
    2. :point_up: helps only for valid examples (i.e. "the happy path"). For invalid examples, the ability to largely copy/paste JSON blobs without much additional stuff would help a lot too. So just seeing such JSON blobs in the *Test.php file then sets the stage/example for others to copy/paste and just swap out the blob :smile:
  • Travis Carden added 1 commit

    added 1 commit

    • 013c14af - Fix an incorrect docblock. [skip ci]

    Compare with previous version

  • Please register or sign in to reply
    Loading