IBM Mainframe Forum

[bravedreamer]

Hi there!

I'm new to the mainframe world and I didn't find anything helpful on the net. Therefore I'm asking you guys!

I want to have a certain level of quality in my code. Therefore, I thought of performing some unit tests. But unfortunately, I found no 'framework' to do that. So my question is: is the creation of such a 'framework' a bad idea? How do other programmers ensure their code quality?

Thanks for your help.

[dick scherrer]

Hello and welcome to the forum,

Many organizations have testing guidelines or standards. Have you asked if these are in place for your environment?

Many organizations have a formal unit test environment, but code is not promoted to this until the programmer is satisfied with their own testing.

If there is no skeleton or "straw man" defined for your testing, it would be a good idea to create one for yourself. Depending on the nature of your code (batch/online, database, vsam, qsam, etc) the testing data would vary.

What i prefer is to set up "contrived data" so that the outcome of a test has an expected result. "Any old data" might be ok for an initial test to ensure the code doesn't crash, but more controlled data should be used eventually. One good thing about contrived test data is that it can be used over and over again with little or no work.

[bravedreamer]

Hey, thanks for the warm welcome.

Yes, I asked if there are any testing guidelines. But since the whole company is somehow in a restructuring process, there weren't defined yet. Maybe in the future but this would be far away.

To your proposal of 'contrived data': I just thought about the same approach. Just create some input data and see if we get the expected result. But I asked myself if there are some 'libraries' that I can already use. So I don't have to create it by myself.

Maybe there are also some libraries (e.g. some includes) that help me to build independing test cases. In principle just as JUnit is for Java.

But I'm satisfied with your answer.

Thanks man!

[dick scherrer]

You're welcome - good luck

d

[BChat]

Hi,

Most companies have test environments set up for the purpose. This is maintained by the client itself. It movement of code is like this...

1) RND - This is the developers test region with full control of the developers. You will yourself copy your code here to do your testing. The data is refreshed from time to time from the UAT as it tends to become very buggy as people play around here. Once you are satisfied you raise requests to move the code to UAT for user to test. It is possible that you have multiple RND region and you are allocated one of them to do your testing. This region has no direct access to production data. May have read access to UAT data (depends)

2) UAT - User Acceptance Testing - this is on the test. But will have controlled access (version control). The developer would ideally have read access to data to aid analysis. The data will be subset of production, but probably masked/scrambled so that it does not require the security that prod needs. User will test on this system to give you the sign-off to move to prod/PAT. This region has no direct access to production data.

3) PAT - Production Acceptance Testing - this resides on the production itself but will have separate CICS or HLQ so that will not clash with prod. It will tested to do parallel run with the prod data itself before deployment. The region will have the same control as the production as basically it is handling production data and needs similar security controls. Can be for large roll-out or migration like changes

4) The production region - the live region

On top of these there can be SIT (System Integration Testing), Training regions etc

Thanks,
BChat

[savvyguy]

Hi BChat,

in this context, may I point to our new unit test tool for the zOS platform which has been designed just for the purpose you ask for! (The paper is English though our web site is not yet, sorry.)

It is designed as a plug-in to IBM's Rational Developer for System z which means it is basically an Eclipse plug-in, plus it allows you to control execution of your unit tests right from your IDE. You can import COBOL copybooks as a basis to define the interfaces you want to test. For these interfaces, you create test scenarios which means you enter input data and define the conditions under which the test is to be seen as successful after the target module has been executed. So everything can be done in one place.

Contact me, if you want to know more. Of course, we are very proud of it.

Cheerio!

[uskobus]

I have heard of a CobolUnit. This is an open source that is similar to Junit.

[dick scherrer]

Hello and welcome to the forum,

Keep in mind that this is an IBM mainframe forum.

This COBOL part of the forum is for IBM mainframe cobol.