Sujet : Re: Fixing a sample from K&R book using cake static analyser
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.cDate : 25. Jun 2024, 09:37:46
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20240625012759.893@kylheku.com>
References : 1 2 3 4 5 6 7 8 9
User-Agent : slrn/pre1.0.4-9 (Linux)
On 2024-06-24, Lawrence D'Oliveiro <
ldo@nz.invalid> wrote:
On Mon, 24 Jun 2024 11:39:49 +0200, David Brown wrote:
>
It's much clearer (to me) to separate the cases and deal
with them individually.
>
Except it becomes difficult to ensure that you have indeed tested all
those cases.
No, it doesn't.
From an external testing point of view, it makes no difference.
External tests only see the API.
If we are looking internally at achieving coverage of key
corner cases, your code organization is definitely worse than
the nice layout into blocks that have a single responsibility.
Testing all the cases is not easy; you need something like a mocked out
allocator that can be programmed to fail after N allocations.
OOM handling code is rarely well tested in real programs.
That's all the more reason why you need an absolute clear organization,
where the OOM stuff is sectioned off away from the happy case, and
you can convince yourself that it's correct by inspection.
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca