Port Tests #2

XedinUnknown · 2021-06-12T14:12:27Z

Just ports the tests from php-fig/log.

⚠️ Requires changes from #1.

This begins porting as per php-fig/log#76 (comment)

XedinUnknown · 2021-06-12T14:15:17Z

@Jean85, I see that psr/log 2.x requires PHP 8. Am I right to assume that the tests will be used with 2.x, and therefore this package can require up to PHP 8.0 as well?

Jean85 · 2021-06-14T08:02:16Z

@Jean85, I see that psr/log 2.x requires PHP 8. Am I right to assume that the tests will be used with 2.x, and therefore this package can require up to PHP 8.0 as well?

No you can't. As said in this other comment, I envision a first release that would be able to replace the original code, and a later release with bumps toward newer PHP & PHPUnit version.

Then, maybe we can do a 2.0 here too, that would require 8.

- Create a padding to provide compatibility between PHPUnit 4 and 8. - Move `TestLogger` to `Stub`. - Add an actual test that will test the `TestLogger`.

XedinUnknown · 2021-06-19T10:33:55Z

@Jean85, GH Actions is not building here. Perhaps needs to be enabled in the settings.

As per php-fig/log#75.

Attempt to make compatible with PHP 5.3.

- Format messages. - Validate log level. - Expose entries. - Normalize entries for test. - Fixed date not having a timezone (important if no timezone set on server).

This ensures that we build on all PHP versions, every time.

XedinUnknown · 2021-06-19T11:31:50Z

@Jean85, the tests are passing for me locally on PHP 5.5. Not sure why they are failing here. If you have any ideas, I'd love to hear them! 😃

tests/AbstractTestCase.php

tests/DummyTest.php

.github/workflows/continuous-integration.yml

This will allow contributors to detect problems faster and easier, avoiding scenarios where a problem is corrected only to find that there is a different problem that was not visible in CI logs before on e.g. another PHP version. See discussion: php-fig#2 (comment)

This reverts commit 82ce817, according to php-fig#2 (comment). See php-fig#3.

See php-fig#2 (comment).

This removes the need for this extra class, giving the test more control. This also re-factors some tests, making them easier to understand.

This was incompatible with PHP 5.3. The new docs far more correctly describe the contract.

In this particular scenario, this is necessary to make the creation of tests easier.

The `setUp()` method signature here was not compatible with later PHPUnit versions due to the `void` typehint in the latter. Debugging output confirmed that a different instance of the logger still gets created for every test after refactoring.

This also addresses php-fig/log#75.

PHPUnit test on at least PHP 5.3 and 5.4 failing because `+00:00` is unrecognized there.

XedinUnknown · 2021-06-21T20:19:54Z

Looks like everything is working.

Jean85 · 2021-06-22T14:26:44Z

Code looks fine for now; I have to compare it with the original code though to understand if we're changing something in their side, to evaluate if the migration from the old code is hard or not.

XedinUnknown · 2021-06-22T14:40:10Z

Maybe I can help. At least, it's these:

Everything has moved at least from Psr\Log to Psr\Log\Util.
Tests (right now, they're all tests) moved from Psr\Log\Test to Psr\Log\Util\Tests.
Stubs (the only stub right now is TestLogger) have received an additional Stub segment, making it Psr\Log\Util\Tests\Stub.
DummyTest has been removed. It is not a test at all, despite its name, and could easily be avoided by appropriately configuring a mock. This is not a BC break, because it had a comment insisting it not be used anywhere.

For now, that is all, I think.

Jean85 · 2021-06-22T14:36:32Z

tests/Stub/TestLogger.php

+        if (!in_array($level, $this->getLogLevels(), true)) {
+            throw new InvalidArgumentException(sprintf('Log level "%1$s" is not valid', $level));
+        }


This check may be too strict, since the spec says:

Calling this method with a level not defined by this specification MUST throw a Psr\Log\InvalidArgumentException if the implementation does not know about the level. Users SHOULD NOT use a custom level without knowing for sure the current implementation supports it.

Maybe we can add a constructor argument to toggle the strictness?

We could, although it would make it more cumbersome, it sounds like it could be a reasonable decision. But IMHO, since this is a test logger (not an abstract one), it doesn't really matter - because this is our implementation that is only used for testing (or is it used/usable for something else?).

My thought would be to make it hot-swappable with the previous implementation, so that it could be easily used in place of the one that we're stripping from psr/log.

Having the behavior toggable would make it just more powerful and adherent to the spec.

Sure, if you think this is the way. If the log level is "invalid", should it silently log it, or silently fail?

Jean85 · 2021-06-22T14:37:53Z

tests/Stub/TestLogger.php

+    public function interpolateContext($message, array $context)
+    {
+        return preg_replace_callback('!\{([^\}\s]*)\}!', function ($matches) use ($context) {
+            $key = isset($matches[1]) ? $matches[1] : null;
+            if (array_key_exists($key, $context)) {
+                return $context[$key];
+            }
+
+            return $matches[0];
+        }, $message);
+    }
+
+    public function formatMessage($message, $level, array $context)
+    {
+        $message = $this->interpolateContext($message, $context);
+        $message = "$level $message";
+
+        return $message;
+    }
+
+    public function getLogLevels()
+    {
+        $reflection = new ReflectionClass('Psr\Log\LogLevel');
+        $constants = $reflection->getConstants();
+
+        return $constants;
+    }
+
+    public function getRecords()
+    {
+        return $this->records;
+    }


All this methods are new and should be documented as new features.

If I were to do it, I would probably add that information to the changelog. Is this what you mean?

On the other hand, like I suggested in another comment, this looks like a totally internal class (I think you mentioned yourself that it is not part of the API that can break etc), merely a stub, and so perhaps it doesn't matter.

Jean85 · 2021-06-22T14:40:31Z

tests/AbstractTestCase.php

@@ -0,0 +1,23 @@
+<?php
+
+namespace Psr\Log\Util\Tests;


I totally missed the namespace issue, maybe from #1.

This namespace is different from before, and it's below autoload-dev, so it's not available to end users like this.

We should move this under src and under autoload. Also, we should check if we want to also copy the old namespace, but that would conflict with psr/log ^1

Oh, I see. I would contend, however, that it still belongs under tests with all the namespaces like this, except it should move to autoload. After all, these are actual tests that we are running on CI.

About conflict with 1.x, I don't think two packages that share a namespace is necessarily a problem, and it is definitely not prohibited: I do it sometimes, when it is semantically advantageous. However, I put them under Util because they are not part of the spec (AFAIK), so it's just utility implementations which as I mentioned before are IMHO not relevant to the specification, just like any other implementation.

Util packages have generally used the Fig\$Lib namespace. The Psr namespace is for the specs themselves, period. We should follow that here.

Including an alias file for the old names is fine if people want to make it a bit easier to transition. (That is, a file that contains a bunch of class_alias statements that people can require if desired.)

Arguably, this would be a massive BC break, though. Is there consensus for applying this here? As far as I understand, the purpose of this PR is to port everything with max compatibility - with both the original spec and the current PHP code. Although, I don't really understand why: people who use psr/log 1.x will have this in that package, and people who use 2.x will need e.g. PHP 8.0 and fixing many BC breaks anyway. So I would suggest maybe putting this stuff back in the original namespace, and then break BC everywhere necessary at once.

With the class aliases, the BC would still be there, and we would also avoid the conflict that I was talking about, so I think it would be the better approach.

Would it not be considered a BC-break if the file with aliases has to be included separately and optionally? Perhaps, we could file-autoload it?

By the way, maybe a philosophical question, but an interesting one to me: is declaration of class aliases code that declares symbols, or code that has an effect?

IMHO it's symbols; but I would file-autoload it and wrap all class_aliases in if (! class_exists(...)) so to avoid conflicts.

XedinUnknown · 2021-06-22T14:43:23Z

I have in mind the idea to do a 2.x upgrade as well. My understanding is that all of the utility classes should move, not just tests. Whether LogLevel etc are utility classes or not - that is not for me to decide, but if it was, my suggestion would be to change it into an interface. I tried requiring the fork of @Crell, but Composer for some reason wouldn't let me install it, and I gave up for now.

Crell · 2021-06-22T14:50:27Z

tests/AbstractTestCase.php

+
+namespace Psr\Log\Util\Tests;
+
+if (class_exists('PHPUnit\Framework\TestCase')) {


Please use TestCase::class et al any time you reference a class, not a string. That's valid since PHP 5.5 and makes the code much more maintainable and readable.

I used a class-string because this upcoming release targets PHP 5.4 and 5.3 as well, and this naturally raises syntax errors. If we change this, we are betraying the spec. Which I would be OK with if you still think this is a good idea, as long as we acknowledge that and do it knowingly 😃

Test classes are not part of the spec, so they can be whatever the heck we want. 😄

The stats from Packagist show that PHP < 5.5 installs are barely 2%, and PHP 8 is 7 times as widely used: https://packagist.org/packages/psr/log/php-stats

So I officially do not give a damn about PHP versions 5.4 and lower.

Test classes are not part of the spec, so they can be whatever the heck we want.

Not part of the spec, but the spec says there's support for 5.3 and 5.4, and strictly speaking we must build on those versions too in order to ascertain that this package actually complies with the spec.

So I officially do not give a damn about PHP versions 5.4 and lower.

Fair enough. Does there need to be some consensus on this, or should I just do it? Sorry, I don't really know how things work between you 😅

Since this is aimed to replace the stripped classes from psr/log, I would support 5.3 but drop it immediately after with another release.

That's what I'd also do, if my understanding of the goals of this first release is correct ☝️

Crell · 2021-06-22T14:58:51Z

tests/Stub/TestLogger.php

+ * @method bool hasInfoThatPasses($message)
+ * @method bool hasDebugThatPasses($message)
+ */
+class TestLogger extends AbstractLogger


I'll be honest, this whole class seems heavily over-engineered to me. I'm working on the logger in TYPO3 right now, and using this as a test anon class:

$this->trackingLogger = new class() implements LoggerInterface { use LoggerTrait; public array $records = []; public function log($level, $message, array $context = []): void { $this->records[] = [ 'level' => $level, 'message' => $message, 'context' => $context ]; } };

Having a pre-made class to help with that is well and good and I'm all for it, but I don't see why that needs 200 lines and dozens of virtual methods (especially when virtual methods are generally evil).

IMO the PHP 5.3 requirement here is at play too, so we can ditch this all with a 2.0 release immediately afterward.

Wouldn't just a records(string $level): array method be ample, and then I can test that however I want myself with the standard PHPUnit tools?

Even in ancient PHP versions, log() like above and a records(string $level): array (even untyped) that returns an empty array if nothing was recorded would be sufficient. Give or take context values, I suppose, but this whole thing can be vastly simplified.

I completely agree with this class being over-engineered. In fact, I have had the thought quite a few times that some methods seem to be extra - and the only method e.g. getRecords() that is really necessary was missing - I added it now. Besides that, there was missing functionality: this test logger wasn't actually interpolating context values into the messages before recording them, and I added that in this PR.

Also, I'm not sure how or whether this was being used in the old package, because AFAIK the only test that is actually running now was added by me, and I can't really think about a different application for this class other than for being used in a test to prove that the test tests what it's suppose to test (sorry for the tautology).

Yet still, my humble opinion is that this change (the possible simplification of this class) should happen in the next BC-breaking release.

Crell · 2021-06-22T15:06:11Z

@XedinUnknown Any class mentioned in the spec should remain in the main spec package, IMO. It's unfortunate that we did it that way back in 2012, in hindsight it's a mistake, but we're stuck with it for now. Utility classes beyond what's in the spec proper are fine to include here, but those should remain in the main package.

Crell · 2021-07-13T14:15:01Z

The spec package updates just passed. What's the status here?

XedinUnknown · 2021-07-15T13:30:25Z

There were some points that remain unaddressed. I was waiting for feedback, and got distracted. I will go through them again and implement directions that are clear, will comment here about this, and wait for feedback on the remaining points.

Seldaek · 2021-07-23T07:30:28Z

The way I see it, any project upgrading to psr/log 2.0+ will need to support PHP ^7.2 (or at least 7 for the scalar hints, not sure if 7.2 is required for psr/log 2). So I would say this util repo could start off at 1.0 supporting only PHP 7.0 or 7.2, and drop the older PHPUnit versions. That would keep things simpler. Projects stuck maintaining PHP 5 have to remain on psr/log 1.0 anyway so they can keep using the abstract test class from there.

Jean85 · 2021-09-01T19:24:28Z

Can we resume the work here? Jordi's suggestion seems good to me.

Crell · 2021-11-10T22:47:24Z

@XedinUnknown Are you going to continue this?

GromNaN · 2022-01-03T16:31:34Z

Hi, this is a friendly reminder. Is there anything blocking progression?

Jean85 · 2022-01-03T22:41:42Z

@XedinUnknown seems unactive. Please feel free to fetch his branch and continue his work following the suggestions from #2 (comment)

GromNaN · 2022-01-05T21:39:35Z

Created an issue to discuss the strategy: #4

Jean85 · 2022-01-12T21:11:15Z

Closing this in favor of #5 + #6

XedinUnknown added 2 commits June 12, 2021 14:51

Include the tests

2bda499

This begins porting as per php-fig/log#76 (comment)

Adjust namespaces

ac26769

XedinUnknown marked this pull request as ready for review June 19, 2021 09:19

XedinUnknown added 2 commits June 19, 2021 12:26

Merge branch 'main' into task/port-tests

2fcda4e

Adapt tests

5e9ac99

- Create a padding to provide compatibility between PHPUnit 4 and 8. - Move `TestLogger` to `Stub`. - Add an actual test that will test the `TestLogger`.

XedinUnknown added 6 commits June 19, 2021 12:35

Remove illegal annotation

2e80eb4

As per php-fig/log#75.

Remove redundant test

2e29776

Correct syntax in test

7fd7e8c

Attempt to make compatible with PHP 5.3.

Correct tests

14ab818

- Format messages. - Validate log level. - Expose entries. - Normalize entries for test. - Fixed date not having a timezone (important if no timezone set on server).

No longer fail build immediately if a job fails

82ce817

This ensures that we build on all PHP versions, every time.

Escape namespace separators in class name

b9b0f04

Jean85 assigned XedinUnknown Jun 21, 2021

Jean85 requested changes Jun 21, 2021

View reviewed changes

tests/AbstractTestCase.php Outdated Show resolved Hide resolved

tests/DummyTest.php Outdated Show resolved Hide resolved

.github/workflows/continuous-integration.yml Outdated Show resolved Hide resolved

XedinUnknown mentioned this pull request Jun 21, 2021

Always continue all jobs even if other jobs fail #3

Merged

XedinUnknown added 11 commits June 21, 2021 21:12

Revert "No longer fail build immediately if a job fails"

60f5ffe

This reverts commit 82ce817, according to php-fig#2 (comment). See php-fig#3.

Remove @internal annotation

9de4c99

See php-fig#2 (comment).

Move DummyTest to Stub sub-namespace

2a66682

Remove DummyTest in favour of a configured mock

b3fc5b0

This removes the need for this extra class, giving the test more control. This also re-factors some tests, making them easier to understand.

Remove callable typehint in favour of PHPDoc/Psalm

4af0554

This was incompatible with PHP 5.3. The new docs far more correctly describe the contract.

Fix PHPCS

ee4e2e3

Allow class re-declaration

c06e685

In this particular scenario, this is necessary to make the creation of tests easier.

Re-factor SUT instantiation

599e7f1

The `setUp()` method signature here was not compatible with later PHPUnit versions due to the `void` typehint in the latter. Debugging output confirmed that a different instance of the logger still gets created for every test after refactoring.

Remove unsupported annotation in favour of explicit method call

0369432

This also addresses php-fig/log#75.

Increase compatibility with later PHPUnit versions

9195cac

Use a named supported timezone

9dff2ae

PHPUnit test on at least PHP 5.3 and 5.4 failing because `+00:00` is unrecognized there.

Add missing fullstop

abca75a

XedinUnknown requested a review from Jean85 June 21, 2021 20:20

Jean85 requested changes Jun 22, 2021

View reviewed changes

Crell reviewed Jun 22, 2021

View reviewed changes

noniagriconomie mentioned this pull request Jul 19, 2021

[Notifier] Add FakeSMS Logger transport symfony/symfony#42123

Merged

Seldaek mentioned this pull request Jul 23, 2021

Don't use the deprecated LoggerInterfaceTest class Seldaek/monolog#1565

Closed

nicolas-grekas mentioned this pull request Sep 13, 2021

Allow psr/log 2.0 Seldaek/monolog#1587

Merged

Seldaek mentioned this pull request Sep 14, 2021

Undo temporary changes for psr/log ^2 support Seldaek/monolog#1588

Open

GromNaN mentioned this pull request Jan 5, 2022

Setup strategy #4

Closed

Jean85 closed this Jan 12, 2022


		namespace Psr\Log\Util\Tests;

		if (class_exists('PHPUnit\Framework\TestCase')) {

Port Tests #2

Port Tests #2

Conversation

XedinUnknown commented Jun 12, 2021

XedinUnknown commented Jun 12, 2021

Jean85 commented Jun 14, 2021

XedinUnknown commented Jun 19, 2021

XedinUnknown commented Jun 19, 2021

XedinUnknown commented Jun 21, 2021

Jean85 commented Jun 22, 2021

XedinUnknown commented Jun 22, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

XedinUnknown Jun 22, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

XedinUnknown Jun 22, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

XedinUnknown commented Jun 22, 2021

Choose a reason for hiding this comment

XedinUnknown Jun 22, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

XedinUnknown Jun 22, 2021 • edited Loading

Choose a reason for hiding this comment

Crell commented Jun 22, 2021

Crell commented Jul 13, 2021

XedinUnknown commented Jul 15, 2021

Seldaek commented Jul 23, 2021

Jean85 commented Sep 1, 2021

Crell commented Nov 10, 2021

GromNaN commented Jan 3, 2022

Jean85 commented Jan 3, 2022

GromNaN commented Jan 5, 2022 • edited Loading

Jean85 commented Jan 12, 2022

XedinUnknown commented Jun 22, 2021 •

edited

Loading

XedinUnknown Jun 22, 2021 •

edited

Loading

XedinUnknown Jun 22, 2021 •

edited

Loading

XedinUnknown Jun 22, 2021 •

edited

Loading

XedinUnknown Jun 22, 2021 •

edited

Loading

GromNaN commented Jan 5, 2022 •

edited

Loading