Sorry... :-D I've got some difficult to find time to fix them... so writing unit tests would make them wait an undefined time... We're still evaluating DbLink for our purpose (with many other tecnology for other application layers)...
I'm not used to test private class members, since a refactoring could invalidate them without a reason, but if the DbLinq coding policy require it I will search a way (I hate friendly assembly! :-D). Be patient... Where should I add the unit test? Is there yet a tester for the DataRecordReader.cs and ExpressionEqualityComparer.cs? Giacomo On Wed, Mar 4, 2009 at 11:27 PM, Justin Collum <[email protected]> wrote: > Yes, leaving your tests for someone else to write is bad form. > > On Wed, Mar 4, 2009 at 2:24 PM, Pascal Craponne <[email protected]> wrote: > >> They look fine. I usually suggest adding unit tests. I committed the patch >> anyway. >> >> >> >> >> On Wed, Mar 4, 2009 at 22:52, Giacomo Tesio <[email protected]> wrote: >> >>> A really small patch... not so deeply tested. >>> >>> In our use case, it works better than before.. :-D >>> >>> >>> >>> Giacomo >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
