We need automated tests for 7.x-2.x. Any refactoring that needs to happen to support this is very much appreciated. Use UnitTests where possible (rather than web tests). This will make the test suite run faster.

Comments

cdale’s picture

cdale CreditAttribution: cdale commented

Short summary of what I believe is in the 2.x branch that might need testing.

  • Provides a Phone field type, Phone field widget, and several formatters.
  • Provides a Phone FAPI element which can be used in custom modules.
  • Backports the "tel" input element from D8 as "phone_tel", and allows this to be used for number input elements.
  • One field instance can support every country.
  • Limit allowable countries.
  • Includes customisable number type/label support (Work, Home, Fax, etc..).
  • Full region level validation for all phone numbers using libphonenumber. This supports most if not all known countries, and works for both the Phone field widget, and Phone FAPI element.
  • Region specific output formatting using libphonenumber, supporting International, National, E.164, and RFC3966 output styles.
  • tel: href support using RFC3966.
  • Full token support.
  • Feeds & Migrate integration.
  • Microdata (itemprop=telephone), RDFa (foaf:phone), and microformats hcard (class="tel/type/value") support. Full type support can be enabled by customising the available number type options.
  • Devel Generate support. Handy, if you need an Acquia sales office phone number.
  • Views and Entity API integration.
cweagans’s picture

cweagans
He/Him
Primary language English
Location Boise, ID, USA
CreditAttribution: cweagans commented

Sounds like a pretty accurate list. I'd also throw in that we need tests for any bugs that get fixed.

cdale’s picture

cdale CreditAttribution: cdale commented

@cweagans Reckon you could chime in on #1928688: Coding details in the 7.x-2.x branch? Wouldn't mind your input.

cdale’s picture

cdale CreditAttribution: cdale commented

What kind of tests are we actually wanting to see here? Testing the API integration works? Or is this where we would test the libphonenumber/phony code?

I'm at a bit of a loss as to what should actually be tested or have tests written for it.

cweagans’s picture

cweagans
He/Him
Primary language English
Location Boise, ID, USA
CreditAttribution: cweagans commented

The libphonenumber/phony code should be tested with PHPunit separately from Drupal, IMO. This would be about testing the integration, the field, etc. A few web tests to ensure that validation, storage, parsing, etc works, maybe one to make sure that the output is what is expected..

Also, we don't have to write all of these at once. We can do this incrementally. I'd just like to have good test coverage for this module (test anything that makes sense to test) so that we don't get weird bugs in the future.