\PHPUnit_Framework_TestCase does not exist in phpunit > 6

For those who want a quick fix here is how you can do it: https://github.com/vanilla/vanilla/blob/19355f36e029cd26c01dfbc5823516ee537578a4/tests/phpunit.php#L5-L13

As per the upgrade bylaw.

• Removes the long-outdated test classes. (This mandates a 2.0 release at least.)
• Add parameter types.
• Add one property type.
• The spec very explicitly allows string|Stringable, so this requires PHP 8.0.
• I also folded AbstractLogger and LoggerTrait together, since they're identical and there's no reason to support PHP 5.3 anymore. I am not certain if this should be considered kosher since AbstractLogger is specified in the spec. It's in its own commit so easy to undo if we decide to.

Corrected all return type-hints from null to void to avoid failed inspections in e.g. Php Storm.

(strict inspection would state that a function must return if annotated with return null - as opposed to return void, which means the function does not use a return-statement and has no defined return-value.)

The @expectedException annotation is deprecated, and removed in PHPUnit 9. When testing with PHPUnit 8, the following warning appears for every time a logger test is run:

The @expectedException, @expectedExceptionCode, @expectedExceptionMessage, and @expectedExceptionMessageRegExp annotations are deprecated. They will be removed in PHPUnit 9. Refactor your test to use expectException(), expectExceptionCode(), expectExceptionMessage(), or expectExceptionMessageMatches() instead.

With PHPUnit 9.5.4, the tests fail with the following error:

Inpsyde\WooCommerceLogging\Tests\Functional\AbstractLoggerTest::testThrowsOnInvalidLevel Psr\Log\InvalidArgumentException: Unknown log level "invalid level"

/home/runner/work/product-woocommerce-logging/product-woocommerce-logging/src/AbstractLogger.php:42 /home/runner/work/product-woocommerce-logging/product-woocommerce-logging/vendor/psr/log/Psr/Log/Test/LoggerInterfaceTest.php:74

Every method accepts a string as the message, or an object with a __toString() method. Implementors MAY have special handling for the passed objects. If that is not the case, implementors MUST cast it to a string.

Changes are made according to the above

Moving a logger injection form the constructor to this trait can result in run time errors as opposed to build time errors. This change provides an error prone way to obtain the logger instance.

As stated in the PHP documentation the __toString has to return a string. Currently the DummyTest::__toString method doesn't comply with this and throws errors like this one in several of my PSR-3 releated packages.

Returning a string from DummyTest::__toString as is expected by the language would solve those errors.

I'm opening this PR to ask if a class like this one would be welcome in this package: http://pastebin.com/AniQf8dw

If the response if not a firm no, I can modify this PR to include a suitable version (no PHP-7, PSR-2 compliant, tests, ...) of that Spy.

Rationale behind the Spy: just a regular Spy. Facilitates testing of classes using a logger. (In my case I'm testing some logging decorators.) Most people would do this via the PHPUnit mock API, though this has a number of problems/downsides compared to using a simple test double like this spy:

• Breaks tools (rename refactoring, find usages, static code analysis) due to referring a method with a string
• Unless doing something complicated will bind to if the production code calls log to a specific level such as error.
• Requires a mocking framework, and developer knowledge of it

There are a couple of things that I have to do to every project I use with the psr logger aware interface and traits, and end up having to create duplicate code every time. It would be nice if we could improve the usefulness of the aware interface and trait.

• Add a getLogger() method that defaults to NullLogger().
• Return static from setLogger() to allow it to be chained.

PSR-3 clearly states that the log method MUST throw a Psr\Log\InvalidArgumentException if a level is given that is not known. However, the interface and the various base implementations are missing the corresponding @throws annotation. Consequently IDEs do not know that such an exception could be thrown. This PR is meant to fix this circumstance.

Please note that I refrained from adding any additional documentation to the annotation, simply because everything else is completely undocumented as well.

PSR-3 claims to use RFC 5424 log levels:

The LoggerInterface exposes eight methods to write logs to the eight RFC 5424 levels (debug, info, notice, warning, error, critical, alert, emergency).

Problem: The log message severity levels are defined as strings, which causes PSR-3 to violate RFC 5424.

http://tools.ietf.org/html/rfc5424#section-6.2.1 clearly defines:

    Numerical         Severity
      Code
       0       Emergency: system is unusable
       1       Alert: action must be taken immediately
       2       Critical: critical conditions
       3       Error: error conditions
       4       Warning: warning conditions
       5       Notice: normal but significant condition
       6       Informational: informational messages
       7       Debug: debug-level messages

       Table 2. syslog Message Severities

RFC 5424 is the successor of RFC 3164. The IETF standard for log message severities exists since 2001.

It's not clear why PSR-3 was entirely modeled after RFC 5424, and even includes literal copies of text fragments, but suddenly diverges from it in LogLevel constant values.

As discussed here this causes PSR-3 to not meet the goal of interoperability (it's primary objective).

I can see two options:

A. Change the constant values to adhere to RFC 5424. (code change) B. Stop pretending that PSR-3 has anything to do with RFC 5424. (textual spec change)

(Incomplete) List of projects that are following the IETF standard:

• Zend Framework 2
• Lithium
• Phalcon
• CakePHP
• Drupal
• IDK Framework
• TYPO3 CMS
• TYPO3 Flow (implicitly by using PHP LOG_ constants)
• php-logger-essentials …only exists to correct this problem.

Out of all other analyzed projects, most are using custom integers (e.g., Monolog, Joomla, Mediawiki).

Excluding the (1-2) projects that migrated to PSR-3 already, this research yielded only 1-2 projects using strings (Yii Framework + another I forgot to record).