Add test coverage for Field API Number

A patch in #557924: Options widget broken presumably soon to be committed shows how to test Field API widgets. It turns out to be pretty easy. We will probably want to move the functions like getTagById() and getOptionByValue() etc. into FieldTestCase in field.test, which is trivial, and then it should be straightforward to crank out widget tests.

This has been fixed in #557924: Options widget broken.

Sorry, Number module still needs tests.

#653074: Review test coverage / outstanding tests before release

some tests were added here: #950134: Number module maxlength prevents saving negative decimal

Number field still has no tests for integers and floats. I'll work on that.

Looks good. Ran tests locally with no problems.

+ 'precision' => 8, 'scale' => 4, 'decimal_separator' => '.', multiline this please.

i cringe when i read + $this->assertFieldByName("{$this->field['field_name']}[$langcode][0][value]", '', t('Widget is displayed')); "{$this->field['field_name']}[$langcode][0][value]" => $value, cant we store that {} thing in $field_name so that the thing is, you know, readable.

I updated the patch per chx's instructions (I hope).

#11: numberfield_test_coverage-558362-11.patch queued for re-testing.

Me and dabl, updated the patch to account for the tests file being moved and the syntax having changed somewhat since the patch was initially written.

Ok, so the invalid syntax is that the patch adds a function that already exists. Without looking in any detail on what the two functions actually do, it seems like this functionality has already gotten into core at some point, and this issue could probably be closed duplicate or works as designed.

needs confirmation that the issue is no longer present?

A testNumberIntegerField() test method was added in #1002734: Multiple "Undefined index" notices in modules/field/modules/number/number.module. At a glance they look similar, but we should compare the coverage and see if we there's anything of value to be added to that test from the patch in #14. testNumberFloatField() and the changes to testNumberDecimalField() are still completely valid from what I can tell.

I've merged #14 with core/modules/number/lib/Drupal/number/Tests/NumberFieldTest.php but it needs more work, as I'm realizing the tests in there are quite inconsistent with each other. I've found another test for number at core/modules/number/lib/Drupal/number/Tests/NumberItemTest.php but this file seems to be dealing with Entity API stuff rather than field and field UI.

Sending to testbot for now, thanks @scor!

Changed LANGUAGE_NONE to LANGUAGE_NOT_SPECIFIED

Changed LANGUAGE_NONE to LANGUAGE_NOT_SPECIFIED

Moving to right component.

Tagging for reroll and unassigning.

Here is a re-roll of this test.

This is another reroll and passes all tests locally. I changed a few items to make it more consistent through out the tests.

Great, thanks for working on this. Quick review.

1. +++ b/core/modules/number/lib/Drupal/number/Tests/NumberFieldTest.php
   @@ -150,45 +150,195 @@ function testNumberDecimalField() {
   +    $this->assertRaw(t('%name must be higher than or equal to %minimum.', array('%name' => $field_name, '%minimum' => $minimum)), 'Correctly failed to save integer value less than minimum allowed value.');
   

   We don't use t() anymore in tests. format_string() must be used now.

2. +++ b/core/modules/number/lib/Drupal/number/Tests/NumberFieldTest.php
   @@ -150,45 +150,195 @@ function testNumberDecimalField() {
   +    // Try to create entries with minus sign not in the first position.
   +    $valid_entries = array(
   +      '-1234',
   +      '0',
   +      '1234',
   +    );
   

   This comment is weird compared to the value used in the $valid_entries array

Thanks for letting me know about the t -> format_string change.

Huh... strange comment there. I've updated it to make it make sense now.

Thanks again!

Oh crap, I messed up with my t() comment - so sorry about that :/

The page which explains the t() usage is https://drupal.org/simpletest-tutorial-drupal7#t - I had to read it again just to make sure.
So basically, you can still use t(), but not in assertion messages. I must have been completely confused when reading the patch.
So you'll have to revert those, again, so sorry :/
But, after that, it's as good as RTBC from me though!

Back to the good one + the small text change, works for me.

Small fix after the rename of field and field instance config entities. Still good to go.

Committed 3d4c167 and pushed to 8.x. Thanks!

Looks like Drupal 7 could still benefit from this coverage?

For D7 this also needs to test just - as inputting just that currently leads to
PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '-' for column 'FIELD_NAME' at row 1: INSERT IN ....

Drupal 7 is now EOL. Moving back to Drupal 8, where it was fixed originally, so that credits are assigned correctly. Thanks everyone!