26 Commits

Author SHA1 Message Date
oleibman 5266086781 Reorganize Samples Part 2
Further reorganization following on PR #3890.
2024-02-04 10:29:41 -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
oleibman 1187825738 PhpUnit 10 Compatibility Part 1 (#3523)
* PhpUnit 10 Compatibility Part 1

This is not a change to move to PhpUnit 10. There is no compelling reason to do so at this time, although it is bound to happen eventually. There are a staggering number of problems (somewhere around 3,000) with the current test suite under PhpUnit 10; this is an attempt to get ahead of the curve by addressing them now.

Method `setOutputCallback` has gone away. This affects only Helper/SampleTest. It appears that `ob_start` and its allies provide an effective equivalent. FWIW, the absence of `setOutputCallback` is a good indication of whether or not PhpUnit 10 is in use, and I will use that fact in a few tests.

Class `ComplexAssert` with no constructor, and always used with `new ComplexAssert()`, extends `TestCase`. Apparently, the constructor for TestCase requires an argument, and PhpUnit 10 complains about not supplying one. Adding an empty constructor to ComplexAssert avoids this problem.

There are two very minor source changes, to Calculation/Calculation and Reader/Xlsx, where problems were exposed with PhpUnit 10 that had not been previously been exposed. AFAIK, these are the only source changes required; the rest of the changes are to test members.

The bulk of the problems are because PhpUnit 10 insists that provider methods be static. Most of those can be changed by a script without any further action; those changes will constitute the Part 2 counterpart of this PR. In this PR you will find the exceptional cases that can't be automated for one reason or another. The tests for Database functions have mild complications that are easily handled. Most of the other provider changes in this PR are because the method names didn't follow an established pattern ('provider' isn't part of the method name); those are also easily handled manually. Modifying the following tests provided significant challenges:
- Writer/Xls/WorkbookTest testAddColor
- Worksheet/Table/TableTest testSetRangeValidRange

The handling of warning messages issued by the code differs in PhpUnit 10. According to the change log, "This means that using PHP functionality which triggers E_DEPRECATED, E_NOTICE, E_STRICT, or E_WARNING or calling code which triggers E_USER_DEPRECATED, E_USER_NOTICE, or E_USER_WARNING can no longer hide a bug in your code." To me, the effect of that change seems to be exactly the opposite - such messages were available to the test with PhpUnit 9 (so we could test for them), and are no longer available (so we can't). I haven't even succeeded with a custom error message handler as part of the script. I will continue to investigate, but, for now, will skip some tests under PhpUnit 10 for the following:
- Shared/OleTest testChainedWriteMode and testChainedBadPath
- Reader/Html/HtmlLoadStringTest testLoadInvalidString
- Reader/Html/HtmlTest testBadHtml

* Scrutinize, and Parent Construct

Parent construct suggested by @MarkBaker.

* Redo Tests Dependent on Warning Messages

Warning (and other) messages are handled differently in PhpUnit 10 than in earlier versions.
2023-04-18 19:50:59 -07:00
oleibman 53e0828d49 Sync composer.lock (#3075)
When I cloned this morning, composer gave me a message that the lock file was not up to date with the latest changes in composer.json. I do not understand why, but it suggested to run `composer update`, which I did. This led to a handful of problems with php-cs-fixer, all fixed with changes to doc-blocks, and phpstan (only Writer/Xls/Worksheet required a change to code). We would presumably have had these problems at the start of next month when dependabot did its thing, so fix them now.
2022-09-20 08:37:00 -07:00
oleibman 2fe66d097f Upgrade mitoteam/jpgraph for Php8.2 Usage (#3058)
They just released a Php8.2-compatible version. We should use that version going forward. Some tests had been disabled in 8.2 due to the problems which the new release fixes; these are now restored.
2022-09-12 08:23:43 -07:00
oleibman 5c13b179a1 Replace Dev jpgraph/jpgraph with mitoteam/jpgraph (#2997)
* Replace Dev jpgraph/jpgraph with mitoteam/jpgraph

PR #2979 added support for mitoteam/jpgraph as an alternative to jpgraph/jpgraph. The package jpgraph/jpgraph is abandoned in composer, and the version loaded with composer has been unusable for some time. This PR removes the dev requirement for jpgraph/jpgraph, and adds a dev requirement for mitoteam/jpgraph in its place.

With a usable graph library, a number of tests and samples that had been disabled are now re-enabled. A lot of new functionality has been added to Charts recently. Some of that new code has exposed bugs in JpgraphRendererBase. I have fixed those where I could. A handful of exceptions remain; I will investigate, and hopefully fix, those over time, but I don't feel it is necessary to fix them all before installing this PR - we are already way ahead of the game with the graphs that are working.

Three members had been ignoring code coverage in whole or in part because of the unavailability of a usable graph libray. Code coverage is restored in them. I am relieved to report that, although they aren't completely covered, adding them did not reduce code coverage by much - it is still over 90.4%.

I took a look at JpgraphRendererBase and Phpstan. Phpstan reports 128 problems. When I added some docblocks to correct some of those, the number increased to 284. Sigh. I will investigate over time, but, for now, we will still suppress Phpstan for JpgraphRendererBase.

I do not find a License file for mitoteam. However, there also wasn't one for jpgraph in the first place. Based on that and the discussion in #2996 (mitoteam will be used in exactly the same manner as mpdf), I don't think this is a problem. IANAL.

* PHP 8.2 Problems

Tons of "cannot create dynamic property" deprecations in jpgraph. Disable the test with most of those for now; leave the two with only a handful of messages enabled.

* Correct Failures in 2 Stock Charts

Down to 6 templates on which Render fails.
2022-08-13 18:14:25 -07:00
oleibman eb34e02085 Restore Tcpdf/Dompdf to Samples in Test Suite (#2814)
They were dropped because they weren't ready for PHP8 when we were. They are ready now.
2022-05-08 11:48:04 -07:00
oleibman f2cd62a9ef PhpUnit and Jpgraph (#2307)
35_Char_render.php had previously been a problem only for PHP8+. It is now a problem for PHP7.4, and will therefore be skipped all the time.
2021-09-26 09:39:15 -07:00
oleibman b98b9c761c Improve Identification of Samples in Coverage Report (#2153)
The Phpunit coverage report currently contains bullet items like `PhpOffice\PhpSpreadsheetTests\Helper\SampleTest\testSample with data set "49"`. This extremely simple change takes advantage of Phpunit's ability to accept an array with keys which are either strings or integers, by using the sample filenames as the array keys rather than sequential but otherwise meaningless integers (e.g. `49` in the earlier cited item). The bullet item will now read `PhpOffice\PhpSpreadsheetTests\Helper\SampleTest\testSample with data set "Basic/38_Clone_worksheet.php"`.
2021-06-11 22:29:44 +02:00
Adrien Crivelli 49f87de165 Reduce PHPStan error in tests 2021-04-12 11:10:23 +09:00
Mark Baker 09022256f4 Resolve Deprecated setMethods() call when Mocking for tests (#1925)
Resolve Deprecated `setMethods()` calls when Mocking for tests, using `onlyMethods()` and `addMethods()` instead
2021-03-15 14:50:05 +01:00
Mark Baker ae2468426f jpgraph seems to be finally dying with PHP. (#1926)
* jpgraph seems to be finally dying with PHP. Until we have a valid alternative, disabling this run for PHP because it errors

https://github.com/HuasoFoundries/jpgraph looks like a natural successor, but it isn't BC so it will require some work to integrate
2021-03-15 14:14:44 +01:00
Mark Baker 08673b5820 Initial experiments using the new Database query logic with Conditional Statistical Functions (#1880)
- Refactoring of the Statistical Conditional functions (`AVERAGEIF()`, `AVERAGEIFS()`, `COUNTIF()`, `COUNTIFS()`, `MAXIFS()` and `MINIFS()` to use the new Database functions codebase.
- Extended unit testing
- Fix handling for null values
- Fixes to wildcard text searches

There's still scope for further improvements to memory usage and performance; but for now the code is stable with all unit tests passing
2021-02-27 18:26:12 +01:00
Adrien Crivelli bd05c590e3 Drop Travis 2020-11-26 11:10:52 +09:00
MarkBaker ee13533db3 Remove tests that include tcPDF and DomPDF libraries when running against PHP8, because neither library is yet PHP8-ready 2020-10-09 14:31:16 +02:00
Adrien Crivelli fcd9f10663 Update PHP-CS-Fixer rules 2020-05-18 13:49:57 +09:00
Adrien Crivelli e868e58d20 Allow to run an entire folder of tests
We now can do something like:

```sh
./vendor/bin/phpunit tests/PhpSpreadsheetTests/Reader/
```
2020-05-17 18:35:55 +09:00
Adrien Crivelli f1a019e492 Upgrad PHP deps 2020-04-27 19:29:45 +09:00
Adrien Crivelli b2070fd181 Upgrade to phpunit 7.5 2019-07-24 23:45:43 -07:00
Mark Baker 1e711541f1 Refactoring xlsx reader (#1033)
Start work on breaking up monolithic Reader and Writer classes into dedicated subclasses to make maintenance work easier
2019-06-30 23:42:25 +02:00
MarkBaker 0ef1b55106 Need to version compare against PHP 7.2.99 for PHP 7.3.0 release candidates 2018-10-14 16:35:38 +01:00
MarkBaker 874467d7c1 DomPDF doesn't yet support PHP 7.3.0, so suppress tests for that combination of version and library dependency 2018-10-14 16:21:40 +01:00
Adrien Crivelli d2f55ffa07 Support PHP 7.2 2018-01-28 16:23:38 +09:00
Adrien Crivelli 8d76020590 Consistent stringFromColumnIndex() and columnIndexFromString()
Column indexes are always based on 1 everywhere in PhpSpreadsheet.
This is consistent with rows starting at 1, as well as Excel
function `COLUMN()`. It should also make it easier to reason about
columns and rows and remove any doubts whether a specific method is
expecting 0 based or 1 based indexes.

Fixes #273
Fixes https://github.com/PHPOffice/PHPExcel/issues/307
Fixes https://github.com/PHPOffice/PHPExcel/issues/476
2017-11-26 15:29:08 +09:00
Gabriel Caruso aed27a0bed Use PHPUnit\Framework\TestCase instead of PHPUnit_Framework_TestCase (#271)
Use the `PHPUnit\Framework\TestCase` notation instead of `PHPUnit_Framework_TestCase` while extending our TestCases. This will help us migrate to PHPUnit 6, that [no longer support snake case class names](https://github.com/sebastianbergmann/phpunit/blob/master/ChangeLog-6.0.md#changed-1).
2017-11-09 00:48:01 +09:00
Adrien Crivelli 40efcd2fdd Rename tests according to the class the class they are testing 2017-11-03 12:47:19 +09:00