Automated Cloverleaf Testing

[Mike Parkinson]

Hi All,

We’re currently in the beginning stages of re-platforming our Cloverleaf server from Window 2000 to Solaris Unix, as well as upgrading to version 5.6.

At the moment, we’re working on developing a test plan to validate all of our translations and TCL procs.  Has anyone been in a similar situation?  We’re looking at ways to automate the testing as much as possible, but we’re a little stumped on the best way to approach it.  It seems like a lot of the testing may have to be done manually, and depending on the level of testing that we do, that could be very time consuming.

If anyone has any thoughts or experience with automating testing, or if anyone has gone through a similar upgrade, I would love to discuss approaches or ideas!

Thanks in advance,

Mike Parkinson

Heath Information Solutions Center

Regina, SK

Topic

[James Cobane]

Mike,

The testing approach we use for upgrades is as follows:

1) Take a copy of the production sites and put them onto the dev box as QA sites.

2) Change all of the threads protocol to file:dev/null.

3) For each inbound thread, using the inbound SMAT file from PROD, run this through on the QA sites.

4) Using a tool such as ExamDiff Pro, compare your newly created outbound SMAT files to the outbound SMAT files from PROD.

5) You can quickly see what, if any, differences there are and determine if it’s an expected difference (i.e. date/time stamps from system date/time) or if it’s a difference due to something unusual.

6) Once this baseline validation is done, then we validate connectivity with the external systems in the TEST environment and do some basic transactional testing with the external systems.  But, the bulk of the validation was done via the Baseline compare to show that everything still looks the same.

Hope this helps.

Jim Cobane

Henry Ford Health

[Anthony Thompson]

(I know this is a rather late reply to this thread, but in case anyone in the future has a similar question.)

I had a similar desire for new development, automated testing of tcl scripts/procs. I ended up mocking the Cloverleaf environment with a library and then using the built-in tcltest package to run the test.

However like creating any comprehensive unit test for code, it’s time consuming. I use it for new development but only go back and add unit tests to old code if I have to rework it substantially.

Depending on how many tcl procs you have, it would be pretty time consuming to go back and add such tests for all the tcl procs in a code base. But it is a great way to document requirements during new development and then have something to run when change requests come in down the road.

[Author]

Replies