Well consider the situation where the programmer doesn't actually have their 
own instance of UniObjects at all, and is only trying to test some external 
unit.  


-----Original Message-----
From: Bill Haskett <wphask...@advantos.net>
To: U2 Mail List <U2-users@listserver.u2ug.org>
Sent: Mon, Aug 13, 2012 6:25 pm
Subject: [U2] Fwd: Re:  Mocking UniSession in .NET


G-Man:

"Despite the latest craze around unit testing and the entire industry 
that it's spawned, I still find applications I use to be as crappy as 
they've always been, so I'm not as enamored with unit tests or mocking 
as many others. "

...maybe even more so!  :-)

You'd think developers these days would have something better to do with 
their time, but then, you've got to do what you've got to do.  :-)    
[sigh...]

Bill

------------------------------------------------------------------------
-------- Original Message --------
Subject:        Re: [U2] Mocking UniSession in .NET
Date:   Mon, 13 Aug 2012 17:28:32 -0700
From:   Tony Gravagno <3xk547...@sneakemail.com>
Reply-To:       U2 Users List <u2-users@listserver.u2ug.org>
To:     u2-users@listserver.u2ug.org


> Brian Leach
> would it be better to construct a higher level wrapper for your business
> functions and mock those? the UO libraries are quite low level: its a bit
> like mocking ado.net rather than your db calls.

> From: Ravindranath
> Thanks for the reply. I am trying to do higher level wrappers to hide
> those UniObject stuff but the problem is in order to to get UniDynArray it
> has to have UniSession. [snip]


Brian, I was going to suggest the same thing. But this is one of the
differences between unit testing an application and mocking, which
will allow a unit test to run completely in test mode without actually
calling to the server within the application code. Ravi could abstract
his code out for the test but that very process could be considered an
invalidation of the test.

Despite the latest craze around unit testing and the entire industry
that it's spawned, I still find applications I use to be as crappy as
they've always been, so I'm not as enamored with unit tests or mocking
as many others. When working on a GUI project I try to get the BASIC
app developers to handle everything there while I intentionally remain
ignorant of their inner processes. Once my clients get the hang of
this they really enjoy the process - the BASIC developers regain their
sense of self-confidence as they realize that a GUI doesn't threaten
their jobs. We interface through well-defined BASIC calls. It's here
that we can do a BASIC mockup of the input to their BASIC code. If
that works, and I've done my job, the GUI will work when linked to the
back-end. Similarly, and (Zzz...) here's the point, my GUI-side tests
don't connect into the DBMS, so I don't need to mock that part. I keep
that interface lightweight, use the same component for almost all DBMS
activity, and don't need the overhead of unit tests or mocking for
every new application. Ravi, that might be of some help to you.

Good luck,
T


_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users




_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

 
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to