The thing I liked about this library and that drew me to it was that it was so easy to integrate into existing projects. Having to add shared code doesn't seem easy. Especially on really huge projects that you just started introducing regular unit tests, precompiled headers alone take a long time to build.
But I'm rambling. It's as good a solution as mine, just accomplishes a different goal. How do we get an executive decision on this, anyhow? I haven't seen either maintainer on this mailing list yet... -----Original Message----- From: Vlad [mailto:v...@demoninsight.com] Sent: November-26-09 6:48 PM To: UnitTest++ development and use Subject: Re: [unittest-cpp-devel] rough idea for a possibly clean/minimally intrusive solution [Re: Testing your privates]] All your production code will really need is the ALLOW_PRIVATE_TESTING declaration, which in itself is just a shortcut (kind of a long one :). There is no compile-time dependency on anything test-related here (the compiler does not need to see the template declaration at that point; you can declare as friends classes that don't exist anywhere). So, all you need to do is have that macro in some shared header or somewhere, outside of UnitTest++ if necessary, -- surely your project already has a few. And it's not like you'll want to test privates of *all* your core classes, right? On Nov 26, 2009, at 5:28 PM, Clark Gaebel wrote: > That's pretty cool. :) > > I do have one concern with it though: the UnitTest++ header being included > in production code. It really shouldn't ever be there. I don't like having > to change what the project will look like just to test it. I like sticking > to the minimal exposure rule: don't use anything you don't have to. > Unfortunately, that has led me to have a need for exposing privates for > testing but not production - hence the patch. Also, this means that either > you will have to bundle it with your project, or risk failing builds. I like > to be able to pull out just the project without the tests at any time. > > The only way I can see this patch satisfying both of us is with a #define > ALLOW_PRIVATE_TESTING before including the UnitTest++ header (in the test > project). ---------------------------------------------------------------------------- -- 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 ------------------------------------------------------------------------------ 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
