[LLVMdev] Private headers and testing

[Misha Brukman]

2009/1/3 Chris Lattner <clattner at apple.com>

> On Jan 2, 2009, at 1:48 PM, Misha Brukman wrote:
>
> 2009/1/2 Chris Lattner <clattner at apple.com>
>
>> On Jan 2, 2009, at 12:21 PM, Misha Brukman wrote:
>> Do you have a specific example of a unit test that would need these?  I
>> really think these should stay private.
>>
>
> Let's take lib/Transforms/Utils/CodeExtractor.cpp .  The public interface
> for it is in include/llvm/Transform/Utils/FunctionUtils.h, with only the
> high-level API.
>
> If I want to test some corner-case (consider the number of code paths in
> that code), I have to strain to come up with some combination of a Function
> and input BasicBlocks that will fit all the conditions from the outset.  Or,
> I can just feed each individual method in the class exactly the corner cases
> I will want it to handle, and verify its output (or side effects) exactly,
> to make sure I pin-pointed the issue.
>
> Sure, ok.  But that is a public API, I'm specifically interested in cases
> you need private API.
>

I'm not sure I understand what you mean.  What I am saying is that I want to
expose the innards of CodeExtractor.cpp in a header file, #include that in
the unittest, and move the implementation out of an anonymous namespace into
llvm::transforms::utils, or llvm::internal::transforms::utils, or similar,
so it can be unit-tested.  This is not about exposing the private API to
end-users of LLVM or even other LLVM libraries, just unittests.

The public API, while useful to the end-user, is limiting when it comes to
unit-testing.  "Unit" in this case is a single method of the actual
implementation (i.e., a method of the CodeExtractor class), not a single
function call of the high-level exported public API, which will exercise the
entire class and its many methods.

Misha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090107/f76ef1b4/attachment.html>