public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Oliver Smith-Denny" <osde@linux.microsoft.com>
To: devel@edk2.groups.io, rebecca@bsdio.com,
	Sean Brogan <spbrogan@outlook.com>,
	Michael Kinney <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [edk2-CCodingStandardsSpecification PATCH 1/1] Prefer use of `static` C keyword over EDK2 type `STATIC`
Date: Mon, 14 Oct 2024 08:22:21 -0700	[thread overview]
Message-ID: <73f096d9-37fc-4b9c-9169-7f70268abdcf@linux.microsoft.com> (raw)
In-Reply-To: <2b59d0dd-3426-4741-a2a9-18275dd613b5@bsdio.com>

On 10/11/2024 9:47 AM, Rebecca Cran wrote:
> I don't know, but I saw a message from Mike recently saying that someone 
> should use 'static' instead of 'STATIC' - so we need to make a clear 
> decision one way or the other.
> 
> 

The problem here is for GoogleTest. In CMocka, if you want to unit test
a static function, regardless of STATIC vs static, you can include the C
file under test in the CMocka test file. Not necessarily the most
elegant solution, but it works.

In GoogleTest, you often cannot directly include the C file in the
GoogleTest file, because C++ complains about many Cisms, mostly
our use of casting. And I definitely don't think we should update
the entire codebase to support compiling under C++ :). Mike, Sean,
and I had a discussion on a Project Mu PR where I undef'd STATIC
while building GoogleTest modules so that static functions could
be unit tested there, too. Also not the most elegant of solutions.

If we switch to "static", we lose the ability to unit test static
functions under GoogleTest in many cases. I don't know if GoogleTest
has some other solution for this, but I don't think so. It may be we
say, yep, that's the limitation of GoogleTest, add it to the
UnitTestFrameworkPkg README, if you need to unit test a static
function, do it in CMocka. But that seems lame, also.

I do believe that unit testing static functions is critical. We should
be doing interface level testing, as well, where static functions are
hidden from us, but there is great value in ensuring each piece of your
code is working as intended from the inside.

Mike, do you have further thoughts here?

Thanks,
Oliver



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120620): https://edk2.groups.io/g/devel/message/120620
Mute This Topic: https://groups.io/mt/108941574/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2024-10-14 15:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-11  1:20 [edk2-devel] [edk2-CCodingStandardsSpecification PATCH 1/1] Prefer use of `static` C keyword over EDK2 type `STATIC` Rebecca Cran
2024-10-11  3:41 ` Sean
2024-10-11 16:47   ` Rebecca Cran
2024-10-14 15:22     ` Oliver Smith-Denny [this message]
2024-10-14 16:47       ` Rebecca Cran
2024-10-14 17:09         ` Oliver Smith-Denny
2024-10-15 21:12 ` Michael D Kinney
2024-10-21 14:49   ` Rebecca Cran
2024-10-21 15:46     ` Michael D Kinney
2024-10-21 19:42     ` Pedro Falcato
2024-10-21 20:05       ` Oliver Smith-Denny
2024-10-21 20:21         ` Pedro Falcato
2024-10-21 20:26           ` Oliver Smith-Denny
2024-10-21 20:35             ` Michael D Kinney
2024-10-21 20:37               ` Oliver Smith-Denny
2024-10-21 21:04                 ` Michael D Kinney
2024-10-21 21:11                   ` Pedro Falcato

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=73f096d9-37fc-4b9c-9169-7f70268abdcf@linux.microsoft.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox