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

Tue Apr 12 07:58:45 PDT 2011

It's not always a dirty hack. For example, the Aspect-J-based wormhole pattern. One of the best pattern names ever!
On Apr 12, 2011, at 9:51 AM 4/12/11, Ryan Hoegg wrote:

> 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
>>>> ·         Speaker: Brett Schuchert
>>>> ·         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
> 
> 
> _______________________________________________
> 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/a68aff0f/attachment.htm>