Rename mis-named data providers discovered in #3421418

Created on 18 June 2024, 11 months ago
Updated 29 June 2024, 10 months ago

Problem/Motivation

In 📌 Add void return typehints to all test methods Active , we noticed a number of data provider methods that were misleading named testSomethingProvider(), rather than the correct providerTestSomething(). These included:

  • DateFormatAccessControlHandlerTest::testAccessProvider()
  • MenuAccessControlHandlerTest::testAccessProvider()
  • JsonApiDocumentTopLevelNormalizerTest::testCacheableMetadataProvider()

There might be others.

Proposed resolution

Rename the methods so that the word "provider" comes at the beginning rather than the end, and update the @dataProvider entries accordingly.

Remaining tasks

TBD

API changes

A few data providers renamed according to standard practice

Release notes snippet

N/A

📌 Task
Status

Postponed

Version

11.0 🔥

Component
PHPUnit 

Last updated about 13 hours ago

Created by

🇺🇸United States xjm

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @xjm
  • 🇦🇺Australia mstrelan

    Do we have a coding standard for this? Seems something that we could use a sniff for.

  • 🇺🇸United States xjm
  • 🇺🇸United States xjm

    @mstrelan, I'm not sure if there's a strict coding standard about data provider naming; I think it's more like a gradually applied best practice. But it is definitely worth considering a coding standard with a rule to go with it.

    Tagging "Needs followup" for that, although it might also be worth checking the coding standards queue for an existing issue about it and/or postponing this on a coding standard rather than fixing it first.

  • Status changed to Postponed 11 months ago
  • 🇦🇺Australia mstrelan

    📌 Define a standard for documenting data providers in PHPUnit-based tests Active is probably the best place to discuss it, postponing on that.

  • 🇺🇸United States xjm

    The other issue did not cover method naming in its scope; it was about requirements for parameter and return documentation. Also, it seems like there's an old, pre-Generator approach suggested that might no longer be relevant (?) so I'm not sure about postponing this on that.

  • 🇺🇸United States xjm

    Updated for the related issue @quietone separated out.

Production build 0.71.5 2024