It is implemented via redefining private and public.
The need for this arose recently when writing a binary search:
class BinarySearcher
{
private:
// Used to bisect the array.
unsigned int GetMidpoint(unsigned int p1, unsigned int p2)
{
Return (p1 + p2) / 2;
}
public:
unsigned int Search(blah blah blah)
{
// This function would use GetMidpoint.
}
};
A bug was later reported that it failed at searching arrays bigger than 2GB!
Can you spot why?
It's because when p1 and p2 are added, it causes an integer overflow. Now
lately, I've been in the habit of writing tests to verify bugs before fixing
them to reduce regressions, but in this case, that's unfeasible.
I would have to do one of the following:
1. Expose GetMidpoint. (Bad)
2. Don't write a test. (Worse)
3. Test the case where a 2GB array would be used. (It's going to be finicky
due to allocation errors)
In the end though, I just made that class behave differently when tested and
not (hence, this patch).
By the way, I thought of another way this could cause problems. If you're
testing code in a .dll or a .lib (or .a/.so), it will cause linker errors
when the linker searches for public functions and finds public ones. There's
an easy way to get around this though, but it leads to a "different" way of
testing things than I think you guys are used to:
#include "UnitTest++.h"
#include "../ClassToTest.h"
#include "../ClassToTest.cpp"
TEST(HelloWorld)
{
CHECK_EQUAL("foo", "bar");
}
This would fix the linker errors, just remember not to link to those libs!
Thanks for the feedback by the way, keep it coming!
***For those interested, the code to fix that bug is: return min(p1, p2) +
abs(p1 - p2) / 2;
On 2009-11-21, at 2:44 AM, Tom Plunket <unitt...@fancy.org> wrote:
> On Fri, Nov 20, 2009 at 5:14 PM, Clark Gaebel
> <cg.wowus...@gmail.com> wrote:
>> Hello everyone - new guy here. I've made a patch to allow UnitTest+
>> + to test
>> private and protected methods, but...
>
> How is it implemented?
>
> Is it simply #define private public, or something more exotic?
>
> I can say that I'm not a huge fan of testing private "stuff," but
> that's just my way of working. My holy opinion is that if something
> is private but the effects of which are not easily observable via the
> public interface, that that bit of functionality should maybe be
> implemented as a separate class and tested separately, and then
> aggregated as a private member into the former class. E.g. "extract
> class" or "extract method" on the functionality that needs to be
> tested.
>
> The alternative is to just assume that the only thing that matters is
> what is observable to the outside world. :)
>
> -tom!
>
> ---
> ---
> ---
> ---------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> unittest-cpp-devel mailing list
> unittest-cpp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
__________ Information from ESET Smart Security, version of virus signature
database 4626 (20091120) __________
The message was checked by ESET Smart Security.
http://www.eset.com
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
unittest-cpp-devel mailing list
unittest-cpp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
