[OKC JUG] Reminder - meeting Tuesday, April 12th

Tue Apr 12 07:51:40 PDT 2011

Also known as a "Dirty Hack"

On Tue, Apr 12, 2011 at 9:41 AM, Brett L. Schuchert <schuchert at yahoo.com>wrote:

> I think even the problem of too many layers can itself be solved by yet
> another indirection later whose implementation is to bypass all the other
> layers )))
>
> On Apr 12, 2011, at 8:59 AM 4/12/11, Lee Meador wrote:
>
> You can solve most such problems by adding a layer of indirection, except
> the problem where you have too many layers of indirection
>
> -- Lee
>
> On Tue, Apr 12, 2011 at 1:05 AM, Brett L. Schuchert <schuchert at yahoo.com>wrote:
>
>> By the way, using a mocking library or not would not fundamentally change
>> how I test either:
>>  the persistent layer
>> clients of the persistent layer
>>
>> So follow-up to last email. Not only "what are you wanting to test, the
>> later itself or clients of the layer". Additionally,
>>
>> what problem(s) are you trying to solve that requires needing to know "how
>> to test persistent layer effectively" - this is a solution to a perceived
>> problem and not a problem itself, so what problem are you trying to solve.
>>
>> If you are meaning to test the persistent layer, does your underlying
>> persistent store's schema make heave use of stored procedures, or are you
>> primarily using an ORM tool (if so, top-down, bottom-up or meet in the
>> middle mapping).
>>
>> If you instead planning on testing clients that use the persistent layer,
>> how does client code get access to an object representing access to that
>> layer (a dao). Does it
>> - use new directly
>> - get it passed in (in a ctor, method, setter)
>> - use some kind of IoC container, e.g. Spring
>>
>>
>> I don't think there's enough time to get more than a superficial hand
>> waving at your question. However, it turns out that the solution to this
>> problem is general. Introduce a level of indirection!-)
>>
>> Brett
>>
>>
>>
>> On Apr 11, 2011, at 8:36 PM 4/11/11, Rupesh Bhochhibhoya wrote:
>>
>> I have always used nice mocks. And didn't really know why other mocks didn't work well for me. So, thanks for info.
>>
>> Also it would be nice if you could share how to test persistent layer effectively using Jmockit.
>>
>> "Brett L. Schuchert" <schuchert at yahoo.com> wrote:
>>
>>
>> Might as well start the talk now...
>>
>>  When using mock libraries, by default use "nice" or "not strict" mocks.
>> Most of them default to strict mocks. The problem with this is that doing so
>> makes the tests more fragile and dependent on incidental complexity rather
>> than essential responsibility.
>>
>>  So in the case of easy mocks, don't use "createMock" by default, instead
>> prefer "createNiceMock". Only use createMock when you really want to verify
>> all messages sent. This is actually a fringe case when doing* focused*unit tests. This is typically counter-intuitive. It only becomes clear as
>> individuals move from tests with lots of checks to focused, single-check or
>> single-logical-check based tests.
>>
>>  OK, discuss...
>>
>>  Brett
>>   On Apr 11, 2011, at 11:05 AM 4/11/11, Rupesh Bhochhibhoya wrote:
>>
>>   I appreciate if you can demonstrate  examples with TDD/BDD. And also if
>> you could show its advantages over EasyMock, that will be helpful too.
>>
>>
>>  Rupesh
>>
>>   *From:* jug-bounces at lists.okcjug.org [mailto:
>> jug-bounces at lists.okcjug.org] *On Behalf Of *Brett L. Schuchert
>> *Sent:* Monday, April 11, 2011 10:52 AM
>> *To:* jug at lists.okcjug.org
>> *Subject:* Re: [OKC JUG] Reminder - meeting Tuesday, April 12th
>>
>>  Oh yeah, I suppose I should prep (mostly kidding).
>>
>>   I already have a "story" for this presentation but I'm open to
>> adjusting if anybody has anything in particular they'd like to me to cover.
>> Just reply to this chain with request.
>>
>>   One thing I will be demonstrating is overriding static methods with the
>> tool - which is cool, too cool, but cool.
>>
>>   Brett
>>   On Apr 11, 2011, at 10:35 AM 4/11/11, Brian Sheldon wrote:
>>
>>
>>   We have a meeting tomorrow. We will be providing food and drinks this
>> month thanks to MBO sponsoring again this year.
>>
>>   Please go register http://okcjug.org/registration so we know how much
>> food to get and who to pick from for the door prize.
>>
>>  ·         Sponsor: MBO Partners <http://www.mbopartners.com/>
>>  ·         Speaker: Brett Schuchert<http://okcjug.org/bios/brett-schuchert>
>>  ·         JMockit <http://code.google.com/p/jmockit/> - Things you
>> shouldn’t do when testing…
>>  Agenda
>> ·         11:30 am – Welcome Announcements
>>  ·         11:40 am – Lightning Talks begin
>>  ·         12:40 pm – Wrap Up
>>  Presentation Information JMockIt is a powerful and easy (perhaps too
>> easy) to use mocking tool that allows you to do things that defy logic.
>> Examples include stubbing static methods, changing final classes and pretty
>> much anything that byte code injection on the fly (per test) allows. We’ll
>> look at some of those things along with more traditional test double
>> creation and then discuss why on the one hand it is nice to have this power,
>> on the other hand you should almost never use it.
>>
>> --
>> Brian
>>  _______________________________________________
>> Jug mailing list
>> Jug at lists.okcjug.org
>> http://lists.okcjug.org/listinfo.cgi/jug-okcjug.org
>>
>>  _______________________________________________
>> Jug mailing list
>> Jug at lists.okcjug.org
>> http://lists.okcjug.org/listinfo.cgi/jug-okcjug.org
>>
>>
>>   _______________________________________________
>> Jug mailing list
>> Jug at lists.okcjug.org
>> http://lists.okcjug.org/listinfo.cgi/jug-okcjug.org
>>
>>
>>
>> _______________________________________________
>> Jug mailing list
>> Jug at lists.okcjug.org
>> http://lists.okcjug.org/listinfo.cgi/jug-okcjug.org
>>
>>
>
>
> --
> -- Lee Meador
> Sent from gmail. My real email address is lee AT leemeador.com
> _______________________________________________
> Jug mailing list
> Jug at lists.okcjug.org
> http://lists.okcjug.org/listinfo.cgi/jug-okcjug.org
>
>
>
> _______________________________________________
> Jug mailing list
> Jug at lists.okcjug.org
> http://lists.okcjug.org/listinfo.cgi/jug-okcjug.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okcjug.org/pipermail/jug-okcjug.org/attachments/20110412/d25e781f/attachment.htm>