Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.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
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | Collection Runner 2016-10-06 12-29-41.png | 90.15 KB | e0ipso |
Comments
Comment #2
dawehnerComment #3
e0ipsoThe 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.
Comment #4
dawehnerJust 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.
Comment #5
mojzis CreditAttribution: mojzis commentedThis could be an inspiration ?
https://github.com/Lakion/ApiTestCase
http://lakion.com/blog/tdd-your-api-with-symfony-and-phpunit
Comment #6
dawehnerThank you @mojzis, thanks really cool!
Comment #7
mojzis CreditAttribution: mojzis commentedAnd 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 ?
Comment #9
michielnugter CreditAttribution: michielnugter as a volunteer and at Synetic commentedI'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.
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.
Comment #10
michielnugter CreditAttribution: michielnugter as a volunteer and at Synetic commentedI'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.
Comment #11
dawehnerNote: #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.Comment #12
rogierbom CreditAttribution: rogierbom at Synetic commentedI 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...
Comment #13
LoMo CreditAttribution: LoMo as a volunteer commentedI 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.
Comment #17
Wim Leers\Drupal\Tests\rest\Functional\ResourceTestBaseand\Drupal\Tests\rest\Functional\EntityResource\EntityResourceTestBasewere added in #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method.And
\Drupal\Tests\jsonapi\Functional\ResourceTestBasewas added in #2930028: Comprehensive JSON API integration test coverage phase 1: for every entity type, individual resources only based on that.IOW: this is already done :)