25

Has anyone come across any workable approaches to implementing test-driven development (and potentially behavior-driven development) in/for COBOL applications?

An ideal solution would enable both unit and integration testing of both transactional (CICS) and batch-mode COBOL code, sitting atop the usual combination of DB2 databases and various fixed width datasets.

I've seen http://sites.google.com/site/cobolunit/, and it looks interesting. Has anyone seen this working in anger? Did it work? What were the gotchas?

Just to get your creative juices flowing, some 'requirements' for an ideal approach:

  • Must allow an integration test to exercise an entire COBOL program.
  • Must allow tests to self-certify their results (i.e. make assertions a la xUnit)
  • Must support both batch mode and CICS COBOL.
  • Should allow a unit test to exercise individual paragraphs within a COBOL program by manipulating working storage before/after invoking the code under test.
  • Should provide an ability to automatically execute a series of tests (suite) and report on the overall result.
  • Should support the use of test data fixtures that are set up before a test and torn down afterwards.
  • Should cleanly separate test from production code.
  • Should offer a typical test to production code ratio of circa 1:1 (i.e., writing tests shouldn't multiply the amount of code written by so much that the overall cost of maintenance goes up instead of down)
  • Should not require COBOL developers to learn another programming language, unless this conflicts directly with the above requirement.
  • Could support code coverage reporting.
  • Could encourage that adoption of different design patterns within the code itself in order to make code easier to test.

Comments welcome on the validity/appropriateness of the above requirements.

Just a reminder that what I'm looking for here is good practical advice on the best way of achieving these kinds of things - I'm not necessarily expecting a pre-packaged solution. I'd be happy with an example of where someone has successfully used TDD in COBOL, together with some guidance and gotchas on what works and what doesn't.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Paul Russell
  • 4,727
  • 1
  • 30
  • 28

3 Answers3

2

Maybe check out QA Hiperstation. It could cost a lot though (just like every other mainframe product).

It only used it briefly a long time ago, so I cannot claim to be an expert. I used it to run and verify a battery of regression tests in a COBOL/CICS/DB2/MQ-SERIES type environment and found it to be quite effective and flexible.

I would say this could be one of the pieces of your puzzle, but certainly not the whole thing.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
NealB
  • 16,670
  • 2
  • 39
  • 60
  • Looks like a serious bit of kit... We'll take a look. Might need to settle for something a little less expensive in the short term though... – Paul Russell Apr 07 '11 at 09:29
1

This answer may not be as easy as you (and I) had hoped.

I have heard about COBOLunit before, but I also don't think it's currently being maintained.

Our team develops an enterprise software product for managing Auto/Truck/Ag dealerships the vast majority of which is in AcuCOBOL.

We were able to break some ground in possibly using JUnit (unit testing for Java) to execute and evaluate COBOL unit tests.

This required a custom test adapter that can serve as the piping and wiring for data between the COBOL unit tests and the JUnit framework. In the application to be tested we will then need to add/design hooks that will evaluate the input as test case data, perform the test to which the data relates, and report results to the adapter.

We are at the beginning of this experiment and haven't gotten much past the "it's possible" phase into "it's valuable". The first foreseeable snag (which I think exists in all TDD) is how to build harnesses into the program.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
SaltpeterBoom
  • 79
  • 8
1

Regardless of how you build/run unit tests, you likely need a summary of how well the tests are doing and how well tested the resulting software is.

See our SD COBOL Test Coverage tool, specifically designed for IBM COBOL.

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341
  • Thanks, looks interesting :) I'm really looking for a framework to execute/report on test runs too though if possible? – Paul Russell Apr 04 '11 at 16:43
  • Recording whether a test succeeds requires some framework, even ad hoc, to record the fact that your test got executed and the status of the results. The COBOLunit thingie you referenced appears to do that. But mostly it just requires that tests have names, and that the execution of a test writes that name and the status to a database that you can inspect later. This doesn't require a lot of logic; you can easily do that by writing your own custom code as a copybook to accomplish this. – Ira Baxter Apr 04 '11 at 19:40
  • Agreed. It's extra things like fixture management that would be very useful too. I'm going to add some more detail to the question to see if that helps. – Paul Russell Apr 05 '11 at 11:09