I got this question recently from a reader, and I thought that the answer might be interesting to others as well:
in my quest to introduce Specification by Example, I just realised that our Mainframe people are going to react with:
“That’s all very nice, but we program in Cobol on the Mainframe, so this won’t work for us.”
That is their usual reaction, to any change.Their fear of change apart, it would be good to know that the technical barrier after which they hide, can fall.Do you know of any tools / people / … that support Specification by Example on Cobol?
I find that specification by example works best when the complexity is in understanding the stakeholder needs and communicating effectively, in particular related to producing requirements and assuring quality, in processes that support frequent software changes. The fact that a team is working in Cobol on a mainframe does not necessarily mean that they have or do not have these issues. If they do experience a lot of rework, low quality, slow change or misalignment of analysis, testing and development, then implementing SBE or some of the ideas of SBE can help. If they do not experience those problems, or those problems aren’t important, SBE is probably not the thing to implement.
In Specification by Example I intentionally do not talk about tools, and in Bridging the Communication Gap the tools are very late in the book. From my experience, many software teams focus too much on a particular tool and not on the collaboration and the process improvement ideas. (I did this as well when I started, we decided to “implement FitNesse”). A tool is important as it helps the process go smoother, but the fact that there isn’t a tool for a particular environment shouldn’t stop you from organising workshops to define specifications collaboratively and illustrating requirements using examples. I know several team that do not automate their tests but still get a lot of value from discussing the specifications collaboratively.
For Cobol and mainframe in particular, I don’t know of any existing tools that integrate with that environment out of the box and my knowledge of that whole ecosystem is very limited. However, many opensource tools have a TCP wire protocol (including Cucumber and Fitnesse), so if their environment can support TCP sockets you can easily implement a link to execute tests with that. Another option is to use TextTest which does checks on text files, so as long as their system produces text output (such as logs) or you can grab some textual record of what happened (such as sql dump into a text file) text test will enable you to describe and automate tests in a way that supports specification by example.
|
|
Hi Gojko,
Interesting question. Some time ago I was doing java development on the mainframe. We were able to run a set of tests on both Windows and z/OS (mainframe Unix equivalent) just using some shell scripting. I’m wondering if you can already use Ruby on z/OS.
That might be a starting point to use Cucumber on z/OS.
Greetz,
Dirk
Well if you can run Java, you can run JRuby, so Cucumber will run.
Dirk, you can probably already use Ruby on z/OS if you’re using USS (Unix System Services) or if you run z/Linux.
It was some time ago I used this tool, but I bet you could cobble together a SbE framework for a COBOL system using VersaTest from Ascert: http://www.ascert.com/home.html
For that matter, you could probably do it using COBOL itself, or some other native mainframe language. I know Perl is supported on a lot of platforms, and HP NonStop (Tandem) has a native interpreted language called TACL that would serve.