Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126176
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 24 Dec 2024 13:37:53 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <2556faa6-c233-4809-8999-afe1af40f4f1@app.fastmail.com>
In-Reply-To: 
 <CAEKnhAHx50FeHw=jpG7=2KmCGGn3CaP491dd6Lti3bxSAw0G1g@mail.gmail.com>
References: 
 <CAEKnhAEFJKPWWL0EKu_JBPgwBEe+Pk3GDzR7HQm3J-g7=Wk0BA@mail.gmail.com>
 <7228b901-a6a9-4aa9-8425-5ad51f66a853@gmx.de>
 <CAEKnhAHx50FeHw=jpG7=2KmCGGn3CaP491dd6Lti3bxSAw0G1g@mail.gmail.com>
Subject: Re: [PHP-DEV] C Unit testing and mocking
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Dec 22, 2024, at 9:23 AM, Jakub Zelenka wrote:
> On Mon, Dec 16, 2024 at 9:05=E2=80=AFPM Christoph M. Becker <cmbecker6=
9@gmx.de> wrote:
>> On 16.12.2024 at 14:18, Jakub Zelenka wrote:
>> > There was a suggestion of RFC but that might be a bit too much as i=
t's just
>> > an internal change / addition. But certainly some overview on inter=
nals
>> > should be done so writing this instead.
>>=20
>> I'm fine with not going through the RFC process, although the policy[=
1]
>> police might come after us. :)
>>=20
>
> I think it fits to all inclusion criteria and doesn't go against any=20
> exclusion. Maybe except that "de facto standard" but for our use there=20
> was really no other option as I mentioned in my comparison so it was=20
> the only library left for our needs if there is only one, then it's "d=
e=20
> facto standard" we could say.
>
> Btw. It was probably mistake to set that policy for C code because we=20
> don't really need to care if PHP recommends any tool there - I=20
> completely missed it when voting for it. This should be just for PHP=20
> application that we care about. We should modify that policy=20
> accordingly - I need to make a list of changes that to the policies as=20
> there are quite a few points.
>
> Regards,
>
> Jakub

Point of order: The recently adopted 3rd party code policy does not appl=
y to C tooling.  It mentions "PHP Tooling", which is defined as "PHP cod=
e run by PHP.net".  The website, docs tooling, etc.  It has no bearing o=
n what C libraries or toolchains can or should be used in php-src itself=
.  (Whether that's unit testing, url parsers, HTML parsers, threading li=
braries, etc.)

I have no opinion or experience on C testing frameworks, other than "yes=
, tests please!" :-)

--Larry Garfield