Problem/Motivation

In the world of an API first approach, it would also make sense to test those APIs. Given that a common test base for those tests could provide a lot of value.

Similar approaches

The soap UI project, which is not just about SOAP but also about REST, has something like assertions build in, see https://www.soapui.org/rest-testing/getting-started.html

There are REST API test frameworks:
- http://frisbyjs.com/
- https://github.com/svanoort/pyresttest
- https://vrest.io/
- https://github.com/Lakion/ApiTestCase

... and probably much more

Proposed resolution

Nothing yet, see remaining tasks

Remaining tasks

  • Research what other frameworks/programming languages / projects provide
  • Suggest how our test base could look like
  • Implement
  • etc.

User interface changes

API changes

- New TestBase for API-based tests. Would need a change record for this.

Data model changes

CommentFileSizeAuthor
#3 Collection Runner 2016-10-06 12-29-41.png90.15 KBe0ipso
Members fund testing for the Drupal project. Drupal Association Learn more

Comments

dawehner created an issue. See original summary.

dawehner’s picture

Related issues: +#2807237: PHPUnit initiative
e0ipso’s picture

The JSON API module will benefit from this. Right now I am using Postman for functional testing. That implies having a drupal installation with some default content to operate upon. Besides, these tests are not run as part of the CI workflow.

I am planning to move those tests to Drupal, this base test case will help me a lot with that process.

dawehner’s picture

The JSON API module will benefit from this. Right now I am using Postman for functional testing.

Just to be clear, BrowserTestBase could totally execute those tests. You would just bypass the mink level and deal with raw http requests using guzzle. This issue is more about finding best practises/making it easy to setup those tests.

mojzis’s picture

dawehner’s picture

Thank you @mojzis, thanks really cool!

mojzis’s picture

And of course, Apiary could be used to describe and test the API. Most of their tools are opensource, so one can add them to their own CI, I wonder though how complicated it would be to add it to the Drupal CI ?

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

michielnugter’s picture

Issue tags: +phpunit initiative

I've been talking offline with @rogierbom and @lendude on exactly this problem and was happy to find out others are interested as well.

I really like the idea of an API test base as we're encountering more and more of these kind of tests, especially since Drupal has a strong API first initiative going on.

Just to be clear, BrowserTestBase could totally execute those tests. You would just bypass the mink level and deal with raw http requests using guzzle

I agree on this point. To me the API test base could very well be BrowserTestBase - Mink + Assertion framework for REST.

Adding phpunit initiative tag as we might be needing this on some of the conversions.

michielnugter’s picture

Issue summary: View changes

I've been taking a quick look at the suggested options and so far I like https://github.com/Lakion/ApiTestCase the most. It's closest to our current set of test bases and it seems easy to use.

dawehner’s picture

Note: #2869839: Move more functionality into \Drupal\Core\Test\FunctionalTestSetupTrait would make the setup a much more smooth process in case we decide to not provide "just" a subclass of BrowserTestBase.

rogierbom’s picture

I would prefer to not make the API test class a subclass of BrowserTestBase. I would instead prefer to strip all things from BrowserTestBase the that we don't need for API tesing, like Mink etc...

LoMo’s picture

I like the idea of using a trait (#11), since that would allow more flexible re-use without worrying about what a test class is based on. That said, I wouldn't mind seeing the BrowserTestBase fleshed out to include more useful functionality.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.