Why COBOL Developers Prefer Writing Tests in Java - Szymon Wałachowski, Bartosz Filipek

uh a couple developers that attended uh told me that it's uh far uh easier to write the unit tests uh in java for them because of all the simple api that we build Uh and it was e easier to write the logic of assertions in Java than in uh COBOL for them. Even though they the their their first language uh of programming is COBOL. We planned. And we designed this API in Java in a way that you don't need to know Java at all.

You just need to follow uh the the brackets. You be just build uh additional layers of customization on top of each other and then you are Tangled with customization. The ultimate goal is to to I I would put it in the short sentence, make uh people's life easier, right? Welcome to Software Testing Unleashed, the podcast for testers, developers, and test automation engineers and all the people in the software development process who want to create great, amazing quality software.

My today's episode was recorded at Testwarez. A great testing conference in Poland. The days were full-packed with great quality content and I had a great time discussing and chatting with the Polish and the international software test community. If you haven't been here, you should definitely Go to one of the next Test Warriors conferences.

You find a link to the conference in the show notes. My guests today are Szymon Wałachowski and Bartosz Filipek. Szymon is a senior software engineer and calls himself A professional no. And Bartosz is a software architect with over 10 years of experience in IT and development.

How can we test a software which ran away from standards and best practices around 40 years ago and uses own solutions for for existing problems. Where no standard works, you have to build your own interfaces. Szymon and Bartosz tell us about their experience, how to test this software and how to build up a testing framework in this environment and now enjoy the episode Hello Szymon, hello Bartosz, nice to have you on the show here. Hello, uh nice to be here.

Thank you for the invitation. Yeah, yeah. I'm I'm I'm very grateful because I saw your abstract here for the test worris. Uh it was uh called uh QA Jurassic Park and I I read through it and I I saw a lot of my client stuff in this little abstract.

You you moved away with your company uh a long time ago from standard implementation of software like that, uh doing your own stuff. Yeah. Customization processing. Yeah.

So so so how how does that come? How does it come? Where should we start, Bartosz? Real good question.

I mean uh in the c on this presentation we talk uh how we um how we actually uh entered the company and starting to understand the environment uh there and uh trace back all decisions that were made And uh actually yeah we reached uh the whole history and we saw that like at the beginning, six years ago. The first uh decision was made uh to build custom software because it was not available on the market. And uh you know how it is with customization. Uh if you d introduce one customization, you need to introduce second customization on on top And so you beard you just build uh additional layers of customization on top of each other and then you are tangled with customization and uh at some point uh they um our company uh couldn't even use uh unit testing uh standard uh tools from IBM for COBOL.

So in in general both legacy and the technical depth is growing, right? Exactly. It's hard to do something with the tools that are not yet available for you and it was something like that uh at least 40 years ago before we were even born actually. So uh yeah the company has 60 years already right we were celebrating uh This year?

This year? Last year. And uh we we don't know. Generations Yeah.

Fast during this uh company history. And what where do you see now the the the big difference from where you where you when you look today at your uh software landscape. So where where do you see the big difference to like standard patterns or standard uh software which is available on the market? Where's the big difference?

Yeah, what's the big difference? You said you talked about the unit tests, so that you cannot use this tool. So w where are the the differences where where you see okay you can you are not In the standard world like we talk about in the conferences or so? a Uh the problem was when one part was missing, the unit testing, all different uh parts were missing like uh for example reporting and so on.

So it's harder to do an uh release if you don't have automated tests that can prove some kind of uh validate some uh Yeah, correctness of the changes and so on. So since one block was missing, a lot of different blocks were missing uh because you couldn't uh establish them. That's why when we introduced this uh uh those the testing tools when we build we build them uh in our uh company it enabled people to use uh all the different kinds of uh tools like uh sonar cube x-ray s uh standard market tools because they were like a bridge from the mainstream world to the So actually we've started the the the race kind of chasing the the standard stuff to to apply uh the modern things in quite old staff right, so uh well We are still a bit struggling with that but we are going I've got a feeling in a good direction so at least we can see that the goal still exists and we have the the tools and approvals from our managers to to to get the right.

Yeah. So the the the road is still long the the the finish line is somewhere there. Yeah. But at least we've we we s we see that on the paper uh everything uh uh is uh where we want it to be.

Yes. We for example we talked uh we talked about it on the uh on the presentation that uh since this uh unit testing tool uh for cobble was written by us in Java. Thanks to that you can uh add additional uh tools like uh cucumber uh Jenkins, uh Alur, uh Sonar Cube, X-ray, thanks to that. So at least uh we are we are still still struggling uh to um Get all the approvals, uh as Barthes said, uh some technical users sometimes.

Even getting technical user on the mainframe sometimes is uh hard. And for example, uh just to uh normalize That it's not a very uh easy road. Uh we can say that for example we struggled to get um service account for one year Yeah. For example.

So actually we are lucky enough to have the support from our direct manager, a bit maybe from the outside, right? So people I think that that and care uh for this kind of stuff right and they they think and they can see also this goal right to to Yeah, it's I think it's a lot of invest in doing internal stuff. Uh so to get your technical depth in in in charge and you can can you can handle that. So and and and I if I uh understand it correctly you you build an extra layer for your uh for uh on on top of your uh customized software landscape to uh to use the normal tools standard tools we have in the market like sonar cube and so yes yes I I I would say I was even uh surprised um once when we were doing the first uh presentation, first time this presentation uh at our office we had a conference uh because our company is also handling uh conferences at the office We are presenting and sabba somebody asked us if since we uh developed those tools in-house, unit testing tool and uh integration testing uh tool.

Isn't that additional customization? And I and I was thinking uh on the stage if this is not uh if we didn't uh make uh also uh the same mistake But we saw that those tools were providing the bridge for the mainframe to the outside market standard tools. And then I realized that actually we built uh let's say one final customization because uh we maybe we introduced some kind of customization uh because of existing c uh cusc customizations in our company. But it was like uh one last customization which should you know switch the uh the workflow from now from uh now on because since You have now uh uh you are able to integrate with everything.

You sh you shouldn't have to uh build additional customizations uh after that. So actually that the task was to build one final customization which should Uh connect us to the uh to the world, let's say. It's it's like an interface. It's an interface interface to the to the standard world.

So it's it's a great uh uh great metaphor, I think, what you just said, that it's like an interface. So it's like building the strangler pattern actually, right? When you have the the huge system the mainframe you want to chop it in the the smaller chunks right and we are trying to achieve something like that also in the long-term perspective if this tool Could be replaced, we are gladly be able to replace it with some standard tool. But on the other hand, we know that uh there is No such thing at least for now from the IBM so we will be missing some support at least for now because the the debugger is the standard IBM tool based on which we are processing all the stuff but on the other hand there is nothing uh similar so I don't know maybe one day They will give it to us also.

Yeah. Exactly. I have my my small function and classes and want to write my unit test in this. It's always the same language.

So I I build my assertions and this stuff. How how the do you transfer this to to uh we're the via the interface to the java world you said uh how does it work maybe let me take the uh the unitesting part and you can take the uh uh test data factory part uh so uh this actually works like little there is a translation let's let's say uh because uh you are writing in using java s syntax, yes uh but we uh Okay, let me let me put it that way. First of all we wanted to use Java because it is giving you all the fancy tools out of the box.

Yes? So that's uh that's why we didn't want to go uh and uh write uh unit tests in COBOL because uh It would be too hard. And we had even uh uh outside company come to uh come come come to us, uh came to us when we were doing the mainframe uh conference at the office And they uh did a workshop on uh the unit testing tool that uh should allow you to write unit test in COBOL. And I was expecting to see that in this part.

Their tool will be better because it's closer to uh people from COBOL. Yeah. But it turns out that uh cobble developers that attended uh told me that It's uh far uh easier to write the unit tests uh in Java for them because of all the AP simple API that we build uh and it was i b easier to write the logic of assertions in java than in uh cobalt for them even though they uh their their first language uh of programming is cool. I was surprised positively and uh they uh their experience was was uh so good because we planned And we designed this API in Java in a way that you don't need to know Java at all.

You just need to follow uh the the brackets, yes, and uh make sure You have open and close. Yeah. Sometimes you need to put the dot. But other than that, you have just simple literals.

There like a variable name, variable value. So it makes uh Writing the test case uh easy uh even if you don't know uh Java. Then it is being translated into uh debug script uh uh debug script which is uh understandable by debugger on the mainframe and this is where we start to execute on the mainframe in the debugging mode and during this debugging mode uh the debug script is uh performing the test case logic for you. So uh uh it's uh stopping at some certain points mocking value uh values if you uh declare declared something like that.

Checking values um at specific points and because of it because it's a debugger you can stop basically anywhere, jump to anywhere. So it gives you a lot of different kinds of possibilities to test uh your program. Okay, sounds sounds very interesting. I think it's uh But as you explained, it's like uh also a little bit of a keyword-driven uh uh approach Where you write your test cases in Java and then the debugger executes them.

The assertions uh work uh it's very similar to the J Unit, let's say, for example, or test ng, right? Where you have uh different kind of assertions and validations, but Honestly speaking, it's not so complicated in the natural, right, in the long run. And having on the other side uh like with the cobble, the plaintext. uh which is not easy to to to maintain and read, honestly speaking, in my opinion.

Yes. It's easier just to even uh set the proper validation because With the cobble probably we would have to provide uh a lot of content. It would have a lot more boilerplate. While within the Java we are just directly pointing to the sections which are actually the functions.

to specific variables that we are checking, validating, right? Because again we have those programs which are quite big And having the the compiled program which has one hundred thousand lines, it's hard to to to maintain and read right. Yes, Osbartos is saying uh thanks to this uh usage of Java instead of COBOL the assertions uh uh require from you less characters to declare Yeah, so it's very uh much much easier uh to to build like for example uh a structure of uh validation individual iterations even of uh For example, you have a section and you execute it in program many times and you want would like to assert some specific uh iterations of uh uh of execution, it's easier to declare it in Java.

than uh probably in cobalt. And uh assertions in general are uh abstract thing. We we we because uh uh it doesn't matter which language Python have a cobalt assertion is just take this variable and Check compare for example. Compare with value.

So so actually uh it's uh language agnostic. So since they are even if they are uh writing in uh Java for them is just a way to express what validation they would uh they would like to see. And um they are They they enjoy uh uh and uh uh they enjoy that uh it's uh even checking the syntax for them in the IDE, uh out of the box and so on. And they and they really like it that that uh you you you The the ID is even giving you hints what you should put here.

Because it's uh checking uh what kind of arguments name there are and Java Docs and so on. Totally new world for totally for the thing. They're like, wow, I would like to share it in Java X Is there a way to to to measure also l something like the code coverage or that do you have something implement because you mentioned Sonacube and Sonacube do a lot of metrics and and checks and so. Uh do you have something similar implemented?

Yes. Yes of course. Uh we are still a bit in progress. Uh it's not fully yet available.

Uh but we did the POC, so we know that it's working, but uh it's an hour back local. So yeah, as we speak it's But still yeah we we have to discuss and uh validate that and verify with the uh the owners which are the COBOL developers, right? and cross-check uh because uh there are some ground rules specific things uh within even our company right for different kind of stuff uh that we want to to focus still on. So it's still ongoing process.

But yeah, as I said, at least we know what we want to achieve and the goal is somewhere there. We know. Yeah, but Bartos is now right now talking a little bit like a business from the business perspective. Yeah.

But from the technical perspective, if you want to know, uh the uh I this debugger has an option just to when you s uh you switch this option on And it's tracking uh which lines were executed. Yeah. Yep. And it's giving you the statistics uh as the outcome.

So you can so we can collect it uh out of the box. Actually, we we don't have to even implement uh anything. Uh so it's uh Fairly easy to to to count count the coverage. Because each test has different cov uh it's covering different part of the code and so on, so you need to com combine them together and uh maybe the unit can do it for you, but uh we still need to validate it with uh customers.

Sure, yeah, yeah. Yeah. And do you have for the future anything in your mind where you think okay w there we have a big epic in the bad backlog what we want to achieve with the with our interface, with our implementation Martosh, do you have some dreams? Some dreams, some a vision for your customization interface.

Actually uh this part for the unit testing this one uh side of the coin. The other side is like the the the second tool that provides you the the ability to interact with the Cobble stuff outside, let's say, of the mainframe, and we are doing that through the REST API because we have this uh universal service that is translating the JSON's to the bytecode that is consumed by the the the mainframe the cobalt programs right and the case is that the ultimate goal uh is to to I I would put it in the short sentence make uh uh people 's life easier right because uh we are trying to to serve them the tool uh that will be handy for them for the unit test but uh also we want to support the qa's people that are not uh cobalt developers right uh it's not like you can learn the mainframe at the the at any kind of university I've got a feeling maybe there is some so I cannot say that it's 100% uh bad, but uh yeah, I I I believe that uh it's still something that you're learning.

once you are joining the company and uh it's easier when you are trying at least uh as a starting point with the more standard tools right And that also brings us to the situation in which we would be able once we will have the unit tests the the functional tests, we will be able to minimize the legacy, maybe pay technical debt, make those cobble. programs a lot smaller we can even chop them into the smaller things right uh and yeah I hope that someday it will be a lot easier for everyone.

Yeah. Intention. I I I I like the idea because I I I not uh know a lot of companies are struggling with the old legacy stuff and to to create to g give effort into it to make it life easier is is always uh a big thing there I think yeah yeah yeah yes. Great.

Uh uh Uh Szymon Batosh, thank you very much for for uh standing here. My questions and uh uh very interesting topic and hope we can inspire some of the people out there. to rethink maybe create an interface if they have some customized old legacy stuff uh to make the life easier Thank you so much and I wish you a good rest day of the conference and then safe travel home.