#2930028: Comprehensive JSON API integration test coverage phase 1: for every entity type, individual resources only and #2932031: Comprehensive JSON API integration test coverage phase 2: for every entity type, complex use-cases added a massive amount of test coverage. In doing so, they increased test run times significantly.

It adopted exactly the test architecture as core's REST architecture. But that test coverage is testing more variations: multiple authentication providers and multiple formats per entity type! So there was more need for isolation.

In JSON API tests, there's less need for isolation. So perhaps we can rename

  1. testGetIndividual()
  2. testPostIndividual()
  3. testPatchIndividual()
  4. testDeleteIndividual()

so that they don't have that test prefix anymore, and call all of them from a single test*() method, that'd reduce the number of installs from 4 to 1 (and 4+N to 1 for those tests that also test special cases).

Thoughts?

Comments

Wim Leers created an issue. See original summary.

gabesullice’s picture

gabesullice
Primary language English
commented

Hm, I feel your pain and I would love to see these sped up.

Won't this mask failures if the first method fails? The following methods won't ever be called. It becomes impossible to see all failures at once, which I like on d.o and when I make a small change that requires tweaking a lot of tests.

Wouldn't running the various test classes in parallel be a more significant speed up? This would mean using the core testbot script.

I'm not completely opposed yet, I just want to be sure the trade-off is worth it.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Won't this mask failures if the first method fails?

Yes. That's a very good point.

I just created this issue because I know some core contributors were concerned about REST's integration test suite. But that one has many more variations (3 authentication providers — cookie + basic_auth + anon and 3 formats — xml + json + hal_json) to test. That's equivalent to running each of JSON API's tests six times.

So maybe it's not necessary to do this for JSON API. Makes me want to mark this "works as designed".

Wouldn't running the various test classes in parallel be a more significant speed up? This would mean using the core testbot script.

That already happens: check DrupalCI's logs: DCI_Concurrency=31, which results in --concurrency "31".

Shall we close this then?

gabesullice’s picture

gabesullice
Primary language English
commented
Status: Active » Closed (works as designed)

That already happens: check DrupalCI's logs: DCI_Concurrency=31, which results in --concurrency "31".

I just meant that we could use this as a local optimization too :)

Shall we close this then?

I think we're okay, yeah. This might become more relevant again once we do complex use cases.