Do you need to send an actual UniDynArray or the underlying data in a dynamic array format? IIIRC the UniSubroutine arguments are overloaded to use strings: and a dynamic array (encapsulated in a UniDynArray) is actually a delimited string. Fields separated by \xFe, values by \xFD, text encoding is 8 bit ansi so get the TextEncoding from page 1252.
Now I dont know what the UniDynArray does internally to manage data but I have found it slow, and often better to go to the underlying string and parse or manipulate it directly e.g. using a List<string>.AddRange( myArray.StringValue.Split('\xFd')); AFAIK the only reason the UniDynArray is constructed from the UniSession is because it needs to get any NLS mappings from the server (anyone know better?) and certainly the older COM implementation of UniObjects did not need a session to create a dynamic array, so you could probably just simulate that and ignore the parenting UniSession. oh and be careful about insert, you probably need replace in most cases. that will replace the content of an existing or non-existing element. Brian Sent from my iPad On 14 Aug 2012, at 20:49, "Ravindranath Wickramanayake" <ra...@rammutual.com> wrote: > Hmm my Business logic sends data to Data Layer then data layer talks to > pick server by using UniObject.NET dll. What I'm trying to unit test is > this DataLayer Calls to pick to check whether it converts complex > objects to UniDynArrays correctly. > > So How do you abstract UniSession out? Sproc coming from pick side > (which I have no control over) require me to send UniDynArray. > > What I want is to send user data to a UniDynArray. I have already > interfaced UniDynArray insert methods but I can't see how I could return > a UniDynArray without a UniSession. Is there a way you could fake > UniSession for unit testing purposes? > > -----Original Message----- > From: u2-users-boun...@listserver.u2ug.org > [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach > Sent: Tuesday, August 14, 2012 4:56 AM > To: 'U2 Users List' > Subject: Re: [U2] Mocking UniSession in .NET > > T > > 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. > > Brian > > -----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: email@example.com > Subject: Re: [U2] Mocking UniSession in .NET > >> 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 _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users