Re: [lmi] On the morality of using const_cast in unit tests

[Vadim Zeitlin]

On Sun, 7 Aug 2016 12:02:15 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-08-03 17:08, Vadim Zeitlin wrote:
GC> > On Wed, 3 Aug 2016 16:18:16 +0000 Greg Chicares <address@hidden> wrote:
...
GC> > GC> The unit test sets up this "what-if" circumstance in order to validate
GC> > GC> class premium_tax's operation.
GC> > 
GC> >  I think the way I'd do this would be to provide a way to test such 
what-if
GC> > scenario in product_database itself by allowing to replace its "db_"
GC> > member. Of course, these methods would need to be private (if we keep
GC> > premium_tax_test as a friend of this class) or be explicitly marked as 
GC> > being for testing only. But if we had them, then, instead of using a const
GC> > case, we could just make a copy of the original DBDictionary and then
GC> > create a product_database representing it:
GC> > 
GC> >   DBDictionary dictionary = db.get_db_dictionary();
GC> >   dictionary.datum("PremTaxLoad") = scalar;
GC> >   product_database dbForTest
GC> >           (dictionary
GC> >           ,... all the usual parameters or, maybe, yare_input
GC> >           );
GC> 
GC> Of course, today there is no product_database ctor that does that, so this
GC> would require new code; and then the code we'd be unit-testing wouldn't be
GC> exactly the same as the production code.

 FWIW I think that unit testing, while absolutely great for a lot of things
(in addition to finding bugs, it allows to also create a better API in the
first place), is not a goal on its own and it's probably fine to have a
completely trivial one line method not covered by it.

 Of course, the divergences between production and testing code should be
avoided if possible, but IMHO it's better to be pragmatic and live with
such (small) divergences rather than spending 90% of total time on getting
rid of 1% difference.

 Regards,
VZ