Re: [Boost-users] Comments / Advice on using Boost Test Library
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Matt Schuckmann
What I'd like to ask the Boost community about is this: how to go about unit testing private class methods.
Hi, Rather than change the interface of my classes to use friend classes (I feel this unnecessarily clutters the interface), I do something simple and evil: #define private public #define protected public # include "MyClass.hpp" #undef private #undef protected Or something along those lines. This is permissable in unit tests, I would think. Sohail
Sohail Somani writes:
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Matt Schuckmann
What I'd like to ask the Boost community about is this: how to go about unit testing private class methods.
Hi,
Rather than change the interface of my classes to use friend classes (I feel this unnecessarily clutters the interface)
I agree...
I do something simple and evil:
#define private public #define protected public # include "MyClass.hpp" #undef private #undef protected
Or something along those lines.
This is permissable in unit tests, I would think.
Yes, this is one of the alternate approaches I've been considering. We've got the "Bad" and the "Ugly". I'm still hoping the "Good" is out there somewhere... :-) ---------------------------------------------------------------------- Dave Steffen, Ph.D. Software Engineer IV Disobey this command! Numerica Corporation ph (970) 419-8343 x27 fax (970) 223-6797 - Douglas Hofstadter dgsteffen@numerica.us ___________________ Numerica Disclaimer: This message and any attachments are intended only for the individual or entity to which the message is addressed. It is proprietary and may contain privileged information. If you are neither the intended recipient nor the agent responsible for delivering the message to the intended recipient, you are hereby notified that any review, retransmission, dissemination, or taking of any action in reliance upon, the information in this communication is strictly prohibited, and may be unlawful. If you feel you have received this communication in error, please notify us immediately by returning this Email to the sender and deleting it from your computer.
# dgsteffen@numerica.us / 2006-09-15 10:49:46 -0600:
Sohail Somani writes:
From: boost-users-bounces@lists.boost.org
What I'd like to ask the Boost community about is this: how to go about unit testing private class methods.
#define private public #define protected public # include "MyClass.hpp" #undef private #undef protected
This is permissable in unit tests, I would think.
Yes, this is one of the alternate approaches I've been considering. We've got the "Bad" and the "Ugly". I'm still hoping the "Good" is out there somewhere... :-)
Extract bodies of those private methods to functors. Call those functors in/instead of your private methods, passing as arguments private data members that were accessed directly in the old methods. class somesuch { int x_, y_, z_; void doFoo() { x_ = y_ + z_; } } becomes struct Foo { int operator()(int x, int y) { return x + y; } } class somesuch { int x_, y_, z_; Foo foo; void doFoo() { x_ = foo(y_, z_); } } This doesn't solve the problem completely, but helps a lot and (AFAICT) always makes much sense from the design point of view, large private methods indicating that the class is mixing policy with mechanisms. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991
Isn't this just a more extreme version of extracting the private methods to another class where they would be public? - R -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Roman Neuhauser Sent: 16 September 2006 18:41 To: Dave Steffen Cc: boost-users@lists.boost.org Subject: Re: [Boost-users] Comments / Advice on using Boost Test Library # dgsteffen@numerica.us / 2006-09-15 10:49:46 -0600:
Sohail Somani writes:
From: boost-users-bounces@lists.boost.org
What I'd like to ask the Boost community about is this: how to go about unit testing private class methods.
#define private public #define protected public # include "MyClass.hpp" #undef private #undef protected
This is permissable in unit tests, I would think.
Yes, this is one of the alternate approaches I've been considering. We've got the "Bad" and the "Ugly". I'm still hoping the "Good" is out there somewhere... :-)
Extract bodies of those private methods to functors. Call those functors in/instead of your private methods, passing as arguments private data members that were accessed directly in the old methods. class somesuch { int x_, y_, z_; void doFoo() { x_ = y_ + z_; } } becomes struct Foo { int operator()(int x, int y) { return x + y; } } class somesuch { int x_, y_, z_; Foo foo; void doFoo() { x_ = foo(y_, z_); } } This doesn't solve the problem completely, but helps a lot and (AFAICT) always makes much sense from the design point of view, large private methods indicating that the class is mixing policy with mechanisms. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
# richard@dynamisys.co.uk / 2006-09-16 16:50:36 +0100:
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Roman Neuhauser # dgsteffen@numerica.us / 2006-09-15 10:49:46 -0600:
Sohail Somani writes:
#define private public #define protected public # include "MyClass.hpp" #undef private #undef protected
This is permissable in unit tests, I would think.
Yes, this is one of the alternate approaches I've been considering. We've got the "Bad" and the "Ugly". I'm still hoping the "Good" is out there somewhere... :-)
Extract bodies of those private methods to functors. Call those functors in/instead of your private methods, passing as arguments private data members that were accessed directly in the old methods.
Isn't this just a more extreme version of extracting the private methods to another class where they would be public?
Dunno, I don't think those things are comparable. One is a matter of improving the design (with better testability as a side effect). The other doesn't influence the design at all. What's so dangerous about algorithms that reside in large private methods? Do those algorithms themselves need to be hidden, or is it access to particular data that needs to be tightly controlled? -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991
participants (4)
-
Dave Steffen -
Richard Howells -
Roman Neuhauser -
Sohail Somani