I think we're actually talking the same thing: a separation between the
business logic and the client.
Mocking the business logic calls so they don't touch the server, and
separately unit testing the server routines so you know they will work when
they will be hit.

And I'm a believer in unit tests, or at least the discipline they enforce -
learned the hard way - and as a platform for integration testing. Without
automated testing I haven't got the resources to do a full integration  test
for every release. Though not necessarily going as far as TDD yet.


-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno
Sent: 14 August 2012 01:29
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Mocking UniSession in .NET

> Brian Leach
> would it be better to construct a higher level wrapper for your
> 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
> 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

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,

U2-Users mailing list

U2-Users mailing list

Reply via email to