Brian,
I cannot remember if we talked about this before, but did you have a 1 common routine which you called from external client programs which then called a FunctionToCall depending on the value of this argument? E.g. Webservice or Windows or Java client code. Call U2Central(FunctionToCall,Action,InData,OutData,ErrText) Where subroutine Subroutine U2Central(FunctionToCall,Action,InData,OutData,ErrText) ...logging ...auditing ...could lookup up Function to see what interface it has then either Call @FunctionToCall(Action,InData,OutData,ErrText) Call @FunctionToCall(InData,OutData,ErrText) Call @FunctionToCall(InData,OutData) Etc. ...logging ...auditing Return This would give a central place for all calls from client programs to do logging, auditing,timing etc... Cheers, Phil. From: [email protected] [mailto:[email protected]] On Behalf Of Brian Leach Sent: Thursday, 11 June 2009 9:31 p.m. To: 'U2 Users List' Subject: Re: [U2] UniVerse Unit Testing Hi At my last company, we spent a lot of effort on building an automated test rig for our software, because we had to support multiple platforms and all our code required full regression testing. It may be a slightly different scenario to yours, since we were primarily building tools, and also this was complicated by the fact that all of our software was client/server in some way, and usually involved several languages .. but here is our experience for what it's worth: The bad news is that you really need to design these in from the start. We designed all our server code as subroutines such that all of our subroutines had one of two calling interfaces, either: Subroutine name(InData, OutData, ErrText) or Subroutine name(Action, InData, OutData, ErrText) That meant that we could generate a test rig that could feed the InData (and Action) and then test for the OutData and log any ErrText values. For reports, we would capture the report text and do 'spot checks' on the expected results. We also version stamped our routines, so we were certain we were testing the right versions, and had build scripts to recompile everything. Nothing left to manual operation since that opens up the opportunity for something to get forgotten: there is no point testing stuff to QA and then doing something different when you come to release! Incidentally, since this was client/server, these involved VBScript scripts for the client end calling cutting paragraphs on the server along the line. Because Universe code doesn't break down into simple blocks, unless you want to instrument your code and capture all your file I/O - which is possible - and test for that, your only sensible option is to unit test at the subroutine/external function level. The good news is that because UniVerse caches subroutines in memory, the overheads to breaking out code are not as high as on systems that do not. it also means you end up with a more manageable system, better options for reuse and if you adopt different client front ends, easier to migrate. You may also find out that your code mass reduces as you split these out, because there is less duplication (sorry if I'm stating the obvious here) and so your testing domain is reduced also. If you want clean-room regression testing, I highly recommend Virtual PC is it will support your OS. We kept clean images of all the platforms we supported, which was a huge time saver. One nice thing about VPC is that it supports 'undo disks' which means that you can snapshot the image at a particular point, and then any changes e.g. brought on by software loads for testing are physically and transparently stored outside the virtual disk and you choose at the end whether to commit those changes or not, making it very easy to go back if that version didn't pass. Finallly, having a predictable way to load routines from dev to QA and from QA to live is a must - so I'll put in a very small [AD] for mvInstaller... Regards Brian ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Perry Taylor Sent: 10 June 2009 20:33 To: [email protected] Subject: [U2] UniVerse Unit Testing The powers that be have been discussing the possibility of going to a unit test model for QA. As I understand the concept, portions of code are broken down into smaller manageable chunks against which a dedicated unit test for each may be run. This seems like a good idea in an object oriented world where methods of object can be easily invoked. This would seem less practical in with a procedural language like BASIC. It feels like we would end up breaking out thousands of lines of code into external subroutines which could then be run through a dedicated unit test. This would introduce significant overhead with all the CALLs to hundreds (thousands) of external subroutines. Then there are complications such as variables in named common, etc. Is anyone out there in MV land employing serious unit testing? If so, care to share your experiences, concerns, success stories? Thanks. Perry Taylor Zirmed, Inc. _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
