Question

As a former java guy with sound testing background, I am now in contact with mainframe / cobol stuff in the financial industry.

I want automated tests, but learned that it is really difficult to implement in our context so I ask here for advice.

1) My plan would be implementing a junit-based test-driver in java to call cobol stuff via stored-procedures, MQ or similar and to check the actual result in various DB2 tables. No problem here from MPOV.

2) The tricky thing is the context / data and here especially the date:

  • Currently tests are done manually.
  • The global "current date" is an important test-parameter and is set manually (and it affects a lot of other programs), so no one else may touch the system during such tests.
  • Because tests are done manually, this lock of global context can easily be tracked: Mails like "do not touch anything on 12.12.2013, I am testing!"
  • When tests are automated, this manual "single tester's global lock" approach is not possible anymore.

=> How can we avoid this single locking? How can things like a global current date, or current exchange rates be easily synthesized?

(current ideas are about cloning the whole context on a daily, weekly, monthly basis. This way one can still lock the given context. But I dislike the idea of "locking" or "owning" at all.)

Was it helpful?

Solution

This is a trick thing with any automated unit testing -- even Junit testing.

The answer is you must pass in the dates. Set up wrappers to "read current date and add it to the parameter list" for production, but have your unit tests call the modules that receive the date.

That is the only way to keep your tests from getting stale in any language or environment.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top