Re: [U2] Unit testing and UniObjects for Java
On 5/8/06, Brian Leach [EMAIL PROTECTED] wrote: Wendy Sorry for the long answer, and some of this sounds like it may be too late, but you've hit a hobby horse of mine here ! (Wow, was it that long ago?) Anyway: Good stuff. :) This is another one of those posts we need to save. May I put the text on the Pick Wiki? But don't worry, you're not too late. What you described is more or less how I write my application code. Each file has a pair of S.A51.WRITE.FILENAME and S.A51.READ.FILENAME subroutines, etc. Probably no two of them have the same set of parameters, but we try. :) The question of unit testing UOJ comes from a different place: framework development. Ever since I discovered Spring JDBC, I've wanted... Spring UOJ. The Spring Framework uses the Template Method pattern (and unchecked exceptions) to turn the mess of try/catch and duplicate code you end up writing to do simple JDBC operations, into three or four lines. Likewise, [what may eventually become] Spring UOJ makes calling a subroutine look like this: UojTemplate ut = getUojTemplate(); //fill Object[] array of params ut.call( subroutineName, params ); However, there *is* a use case for a simple read without forcing people to write and catalog a subroutine. (Less so for a write, IMO.) So I wrote the 'read' method for the template... and discovered that the design of UOJ makes it *really* hard to unit test. Part of this is simple frustration with not having the source code, and not having the 'asjava.jar' file publicly available makes it hard to ask questions on other lists. (More on that later-- we need to get the UOJ jars into the public Maven repository on ibiblio, but I'm not sure what license they're under.) -- Wendy --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Unit testing and UniObjects for Java
Brian Leach wrote: I ALWAYS teach clients to write all the business logic in server subroutines first for any client/server or web project - and for precisely this reason. Debugging any client/server program is difficult and time consuming, web/multiplexed programs even more so, tracking down where errors occur (especially if you have different teams for front and back end) is bad news and there is also the 'hey wow' factor of the front end obscuring development and testing of the business logic. I have to agree with you. That's the methodology we've always used here, and it has stood the test of time. Keeping all the business logic on the UV side allows another UV developer to write and test an entire application without having the java application in a working state. If I'm not done with the various servlets and jsp pages, my coworker can write a simple green-screen front end that mimics the I/O that the web application would be doing. Also, if you need to do any text formatting or parsing, this is much easier in UV than java. I recently wrote a method to take a dollar amount stored in a string variable and multiply it by an integer quantity, then return the result as a string. It took 18 lines of code in java where I probably could have done it with 1 line in UV BASIC. -John -- John Hester System Network Administrator Momentum Group Inc. (949) 833-8886 x623 http://memosamples.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Unit testing and UniObjects for Java
Wendy Sorry for the long answer, and some of this sounds like it may be too late, but you've hit a hobby horse of mine here ! It looks from your example (and apologies if I am misreading this) that you have business logic and file interaction inside your UO code. That really makes life hard. I ALWAYS teach clients to write all the business logic in server subroutines first for any client/server or web project - and for precisely this reason. Debugging any client/server program is difficult and time consuming, web/multiplexed programs even more so, tracking down where errors occur (especially if you have different teams for front and back end) is bad news and there is also the 'hey wow' factor of the front end obscuring development and testing of the business logic. So the route I always teach (and hopefully follow grin ) is: 1. Write all the database interaction as subroutines. 2. Where possible use a standard calling convention - I know this goes against the grain for some, but it is specifically to allow logging/debugging/testing using a simple harness: Call MySubroutine( Action, InData, OutData, ErrText ) Where InData, OutData are dynamic arrays, ErrText adds error text to a dynamic array of error messages, and Action allows the routine to vary e.g. new for a new version whilst retaining backward compatibility. 3. Then I recommend people QA the server before even THINKING about the front end: if it is well designed, the subroutine library effectively becomes an API for you application and can be reusable eg. From UO (or UOJ in your case), web applications such as mvScript (quick plug) or RedBack via interface subs, the new U2 web services etc. It is also comforting to be able to concentrate on the client whilst knowing that the logic behind it is secure. 4. Since the front end is the more likely to change, this route isolates the logic but a good test harness should allow for regression testing at the server. 5. Since I use a standard calling convention, I can use a single function to call the server. Which means I can use a single place to add logging/auditing etc and and I guess I could also write a dummy function to simulate this (though that is a step I haven't had to perform yet - I just use refreshable test account on virtual PC images) against another source. I would also recommend NOT doing opens, reads, executes, select list handling etc directly in UO - not because they do not work, but because your logic gets scattered. That was a lesson I learned early on in the days of VB and UO when I took on a project where the requirements changed almost weekly: it eventually became unmanageable and I wasn't proud of the result (though it delivered what they wanted :) ), but boy did it teach some lessons! Keeping all the business logic in one place is a high priority: we don't need mainstream 3 tier logic as we have the database run machine to provide the logic tier. Just keep everything there where it works, and everything will be fine: but as soon as you allow it to creep into the presentation layer, you will be storing up trouble. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wendy Smoak Sent: 05 May 2006 19:45 To: u2-users@listserver.u2ug.org Subject: [U2] Unit testing and UniObjects for Java I'm going to set this project aside for the day, but I want to toss the question out to see if anyone else has an answer. I'm having a horrible time trying to unit test code that uses UOJ. In the past I've just 'cheated' and tested against the database itself, but that really shouldn't be necessary. It's also not unit testing as the tests then cover the interaction between the code and the database. Here's an example of the code under test: uFile = uSession.openFile( filename ); uString = uFile.read( key ); I'm attempting to mock the UniFile object, but I get: asjava.uniobjects.UniFileException: Cannot instantiate this object in this manner. Must use the UniSession object (So why even *have* a default constructor in UniFile?) I'd love to hear how you're unit testing your UOJ dependent code. Thanks, Wendy Smoak --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Unit testing and UniObjects for Java
Great post Brian It made me think about some of the code I'm working on right now and I think I'll make a few changes as a direct result. Thanks! Rob Wills (rob dot wills at tigerinfotech dot com) --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Unit testing and UniObjects for Java
Mainly using Nunit for .NET but this is derived from Junit. Highly recommended *. http://junit.sourceforge.net/ From: Wendy Smoak I'd love to hear how you're unit testing your UOJ dependent code. ** This email message and any files transmitted with it are confidential and intended solely for the use of addressed recipient(s). If you have received this email in error please notify the Spotless IS Support Centre (+61 3 9269 7555) immediately, who will advise further action. This footnote also confirms that this email message has been scanned for the presence of computer related viruses. ** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
