Testing private methods in Boost
Is their a good strategy for testing private methods in a class using Boost? I am looking for something that is non-intrusive to the developed code, but I can't think of any good ways without modifying the code under test. Thanks, Herb Miller
On 06/08/2010 01:54 PM, hmiller@hiwaay.net wrote:
Is their a good strategy for testing private methods in a class using Boost? I am looking for something that is non-intrusive to the developed code, but I can't think of any good ways without modifying the code under test.
#define private public #define protected public #include "MyClass.hpp" #undef protected #undef private That's the horribly wrong answer. The right answer is "don't test privates except through the public interface". Testing private methods explicitly will result in classes that are hard to refactor because the unit tests, upon which one relies heavily during any refactoring exercise, constrain the implementation. Regards, Rob
Hi,
If it is too hard to test your private methods via the public
interface then it maybe a sign that your class could use a little
refactoring and you may want to move code to separate utility/helper
classes.
Best regards,
Mau.
2010/6/8 Rob Riggs
On 06/08/2010 01:54 PM, hmiller@hiwaay.net wrote:
Is their a good strategy for testing private methods in a class using Boost? I am looking for something that is non-intrusive to the developed code, but I can't think of any good ways without modifying the code under test.
#define private public #define protected public #include "MyClass.hpp" #undef protected #undef private
That's the horribly wrong answer. The right answer is "don't test privates except through the public interface". Testing private methods explicitly will result in classes that are hard to refactor because the unit tests, upon which one relies heavily during any refactoring exercise, constrain the implementation.
Regards,
Rob _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Mauricio Gomes Pensar Digital 55-11-9698-1683 (Brazil - mobile)
Thanks for all of the replies. They all have merit, and I will be trying them today. Herb Miller
On Tue, Jun 8, 2010 at 3:54 PM,
Is their a good strategy for testing private methods in a class using Boost? I am looking for something that is non-intrusive to the developed code, but I can't think of any good ways without modifying the code under test. Thanks, Herb Miller
Either add a public function 'internal_test()' to the class, and have it run the tests, or add a friend class. Yes both of these are a bit intrusive. Adding a friend class is really bad as it breaks the encapsulation. Having a public function that does internal testing doesn't sound too bad to me. Keeps the encapsulation, allows tests to be close to the code it is testing. Tony
If you class has a function template (public, protected or private) you can
specialize this function template with some custom type and gain access to
it. With protected or private you have to trix around. With public it is
pretty straight forward:
class my_class
{
public:
template<class T>
void some_entry_point();
private:
void my_secret_function()
{
//...
}
};
// test code:
namespace
{
struct my_secret_type_to_specialize_entry_point {};
}
template<>
void my_class::some_entry_point
Is their a good strategy for testing private methods in a class using Boost? I am looking for something that is non-intrusive to the developed code, but I can't think of any good ways without modifying the code under test. Thanks, Herb Miller
[Please do not mail me a copy of your followup] boost-users@lists.boost.org spake the secret code <20100608145455.1645315v636o5csv@webmail.hiwaay.net> thusly:
Is their a good strategy for testing private methods in a class using Boost? I am looking for something that is non-intrusive to the developed code, but I can't think of any good ways without modifying the code under test.
Don't be afraid to move the hard-to-test stuff to a new class and delegate to the new class from the old one. That doesn't change the visibility of the old class and the new class needn't be published in any public API if you want to keep it hidden. However, the new class can have methods with any visibility you like. Michael Feathers calls this technique "Break Out Method Object" in his book "Working Effectively with Legacy Code", which I review here: http://legalizeadulthood.wordpress.com/2007/04/11/working-effectively-with-l... Generally the situation you describe comes up most often when you try to retrofit tests onto existing "legacy code" (code without unit tests). I find that when I practice test-driven development, then things just work out naturally. My tutorial on using Boost.Test also gives you a way to practice test-driven development with C++ and Boost.Test: http://legalizeadulthood.wordpress.com/2009/07/04/c-unit-tests-with-boost-te... -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/ Legalize Adulthood! http://legalizeadulthood.wordpress.com
participants (6)
-
Gottlob Frege -
hmiller＠hiwaay.net -
legalize+jeeves＠mail.xmission.com -
Mauricio Gomes -
Ovanes Markarian -
Rob Riggs