Re: C Unit testing and mocking
On Sun, Dec 22, 2024, at 9:23 AM, Jakub Zelenka wrote:
> On Mon, Dec 16, 2024 at 9:05 PM Christoph M. Becker <[email protected]> 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 it's just
>> > an internal change / addition. But certainly some overview on internals
>> > should be done so writing this instead.
>>
>> I'm fine with not going through the RFC process, although the policy[1]
>> police might come after us. :)
>>
>
> I think it fits to all inclusion criteria and doesn't go against any
> exclusion. Maybe except that "de facto standard" but for our use there
> was really no other option as I mentioned in my comparison so it was
> the only library left for our needs if there is only one, then it's "de
> facto standard" we could say.
>
> Btw. It was probably mistake to set that policy for C code because we
> don't really need to care if PHP recommends any tool there - I
> completely missed it when voting for it. This should be just for PHP
> application that we care about. We should modify that policy
> accordingly - I need to make a list of changes that to the policies as
> there are quite a few points.
>
> Regards,
>
> Jakub
Point of order: The recently adopted 3rd party code policy does not apply to C tooling. It mentions
"PHP Tooling", which is defined as "PHP code run by PHP.net". The website, docs
tooling, etc. It has no bearing on what C libraries or toolchains can or should be used in php-src
itself.. (Whether that's unit testing, url parsers, HTML parsers, threading libraries, etc.)
I have no opinion or experience on C testing frameworks, other than "yes, tests please!"
:-)
--Larry Garfield
Thread (13 messages)