How to unit test with functions not in header

[keltion]

Dear All,

I want to write a test code for `TextFieldIntrinsicInlineSize` function. 

This function is defined in third_party/blink/renderer/core/layout/layout_box.cc and is called only in the `DefaultIntrinsicContentInlineSize` function defined in the same directory.

In other words, the `TextFieldIntrinsicInlineSize` function is not declared in the header file. 

In this case, I wonder if it is enough to write a test code for `DefaultIntrinsicContentInlineSize` to test for `TextFieldIntrinsicInlineSize` . 

Could you teach me if there is a better way?

Thanks,

keltion

[Kalugin Alexander]

I had the same problem once. Solved by exposing function via auxiliary *ForTesting() function.
See comment and CL: https://crrev.com/c/chromium/src/+/1947644/6#message-67077a37da0fc852d8985cd6a839169f069795f5

суббота, 28 мая 2022 г. в 06:31:48 UTC+7, chatt...@gmail.com:

[Christian Biesinger]

I would add the function to the header file, perhaps as a static member of LayoutBox.

Christian

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/722e1054-b8bc-429b-a316-5b6af1ba8774n%40chromium.org.

[Roland Bock]

I would try to stay away from testing this function directly.

Tests should test the public API. They should focus on the what, not the how.

Implementation details are called implementation details for a reason. The implementation could change at any time as long as the public API stays the same.

Also note that once you add the function to the header, it is part of the public API.

People might start to depend on it. It is not a detail any more.

Just my 10ct.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAPTJ0XF-wV0dTNwTeLyfkqrFDRSYxxeoVOKY9ra3gBtpvj_Y1g%40mail.gmail.com.

--

--

Roland Bock

Software Engineering Manager

rb...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

The above terms reflect a potential business arrangement, are provided solely as a basis for further discussion, and are not intended to be and do not constitute a legally binding obligation. No legally binding obligations will be created, implied, or inferred until an agreement in final form is executed in writing by all parties involved.

[Christian Biesinger]

If that's a concern, you can make it a private function and use FRIEND_TEST/FRIEND_TEST_ALL_PREFIXES

FWIW I disagree that tests, especially unit tests, should only test the public API. It is often valuable to test that certain internal helper functions do the right thing especially if the API is relatively complex (like in case of LayoutObjects...)

Christian

[Dmitrii Kuragin]

Hi,

You don't in general. All you have to test is the external contract which is provided by header file. You also, have to consider what is your "unit".

For some details, see https://abseil.io/tips/135

Basically, the internal structure (internal helper functions, sometimes even separated into different files) shouldn't affect unit tests. So, that the tests are not coupled to the particular code structure and refactoring stays possible.

But, in some cases, it might be that the unit grows and it became very difficult to test the all use-cases with higher-level API, but it require some reconsideration of what "unit" is and likely would lead to some separation of concept. 

Also, take into account performance. Unit-tests are supposed t be fast, so people would be able to run them more frequently.