14 Commits

Author SHA1 Message Date
oleibman 645d9fea64 Phpstan Level 10 Prep Penultimate
Everything except Statistical.
2025-05-18 18:04:25 -07:00
oleibman ec773bbed9 Phpstan Bleeding Edge Part 2 of Many
This will be the biggest of these changes. It takes care of all of the remaining problems in tests. I will handle the problems in src more slowly.
2025-02-15 19:18:39 -08:00
oleibman d647fe7ee7 Use Php Attributes Rather than Annotations for PhpUnit
With PhpUnit 10 came the ability to use Php attributes rather than doc-block annotations for things like "data provider". PhpUnit 11 deprecates the use of annotations, and PhpUnit 12 will not not permit their use. Since PhpUnit 11 requires Php8.2+, we cannot adopt it as long as we support Php8.1, which will continue to be the case for some time. However, there is no penalty for early adoption.

Php-cs-fixer can use:
```
'php_unit_attributes' => ['keep_annotations' => false],
```
This allows us to run `composer fix` to automate all the needed changes. No manual changes were needed for any of the test members.

With this change, PhpUnit 9 can no longer be used with the test suite. File composer.json is updated to reflect that reality, and phpunit9.xml.dist, which has been supplied in case anyone needed to use PhpUnit 9, is no longer required, and is thus deleted. For now, PhpUnit 11 is not being added as a possibility.

No source code is changed in this PR.
2024-11-23 20:56:26 -08:00
Adrien Crivelli ec4098c8fd Strict mode for all tests
While we might never be able to have 100% of our code strict, we can at
the very least do it for all of our tests. This ensures that our tests
are using our API with the types as intended by the test author, and not
silently be cast to what our API requires.
2023-09-07 17:44:56 +08:00
Adrien Crivelli 1b05dfab8b Rector AddParamTypeBasedOnPHPUnitDataProviderRector
And quite a bit more manual changes. The idea is that typing of our
tests can be a bit more loose, so we assume PHPDoc is mostly correct. If
that happens to be wrong, it should be caught by the tests themselves.
2023-09-07 17:00:24 +08:00
oleibman e9cf27354d PhpUnit 10 Compatibility Part 2 (#3526)
Successor to PR #3523. There are 494 single-line changes (`public function provider` to `public static function provider`) in this PR. None of these were made manually; they were all created with the following script (adapted from
https://stackoverflow.com/questions/25909820/how-to-recursively-iterate-through-files-in-php):
```php
$dir = 'C:/git/unit10prep2/tests/PhpSpreadsheetTests';
$it = new RecursiveDirectoryIterator($dir);

// Loop through files
foreach(new RecursiveIteratorIterator($it) as $file) {
    if ($file->getExtension() === 'php') {
        $contents = file_get_contents($file);
        $new = preg_replace('/public function (\\w*)([Pp])rovider/', 'public static function $1$2rovider', $contents);
        if ($new !== $contents) {
            echo "changing $file\n";
            file_put_contents($file, $new);
        }
    }
}
```

After this PR, there will be one more, with a small number of test changes, and enabling PhpUnit 10 for Php 8.1+.
2023-04-20 13:48:00 -07:00
MarkBaker 3d7964f568 Improve support for locale settings in the Calculation Engine formatted number matcher 2023-02-17 08:03:28 +01:00
MarkBaker 4aaf1f61b9 Allow a range of different potential currency codes (including the locale code) in the currency matcher regexp
(dollar, euro, pound sterling and yen)
2023-02-17 06:16:10 +01:00
MarkBaker 04be65aee8 Allow thousands separator in formatted numeric strings to be handled as numbers by the Calculation Engine 2022-11-25 20:03:48 +01:00
MarkBaker 12581cbb72 Allow thousands separator in percentage formatted strings used as numbers by the Calculation Engine 2022-11-25 19:13:20 +01:00
MarkBaker 171d7684d6 Allow currency numeric strings with thousands separator 2022-11-25 13:15:10 +01:00
fjohnston@avatarasoftware.com 66da98ebb8 Handle Currencies Stored as Strings in Formulas
Added a function to the new `FormattedNumber` helper that will use the currency code pulled from `localeconv` by `StringHelper::getCurrencyCode()`.  The currency code is `preg_quoted` and then dropped into a regexp that is modelled on the expression developed for `convertToNumberIfPercent`.  This will allow locale independent operation.
Unfortunately `localeconv` only provides information about standard currency formats and not accounting formats.  This means that we can't say for sure whether or not a locale has an accounting format where the currency symbol shows up in a non-standard position (eg. left justified for some countries instead of appearing directly in front of the value).  The regexp should handle these cases.

The primary issue with this approach is that the regexp will incorrectly match invalid currency formats for some locals as it checks for the symbol before and after the value.

A possible improvement would be to pull `p_cs_precedes` and `n_cs_precedes` from `localeconv` and using them to determine if the currency symbol should appear before or after the value for the current locale.  Since white-space is ignored by the regexp, accounting formats should still work, as long as the accounting format doesn't involve moving the symbol to the opposite side of the value.
2022-11-18 14:54:48 -05:00
MarkBaker d7a2315c8e Additional unit tests 2022-11-11 12:28:26 +01:00
MarkBaker f5beafd845 Refactoring for checks on strings containing formatted numeric values when used in mathematical operations in the Calculation Engine 2022-11-11 12:28:26 +01:00