For PowerBuilder projects using PowerScript language, we have some customers successfully using PBUnit.  But this is not something that we integrated so we don't provide technical support for it.

For PowerBuilder projects using C# language, we have integrated xUnit and provide technical support for this combined solution.  And since it is standard C# you can actually use any unit testing framework for .NET in case you don't want to use xUnit.  We have some customers using NUnit for example.

Hi Armeen,
Thank you very much for the quick response, but we are migrating old projects in PowerBuilder 10 for PowerBuilder 2019, and what we need are unit tests in PowerBuilder Classic.
Is Appeon planning to have some integration of unit tests and thus support unit testing?

Thanks in advance.

I have used PBUnit in the past.

I customised it a fair bit to do some things I wanted, but most of our business logic is not in non-visual objects, and it would just take too much time to move it it. For the few we did use it for it worked pretty well at the time.

For C# code I am using nunit at the moment, but will be happy to take a look a xunit in the future.

Hi Armando, Reflecting on Aaron and Armeen's replies >

PBUnit is a worthy attempt to provide unit testing framework for PowerScript code. I'm not aware of successful competitors - except writing your own test framework tailored to your environment.

However - a word of caution before you design your first unit test but find it hard to find the "unit" to be tested >

Unless testability + high cohesion + "no accidental coupling" were always center stage during prior software design + coding - - - well, then you probably have code that is very hard to unit-test!

It has nothing to do with PowerScript. I have seen such behavior in every language I've touched (and I've touched quite a few). And it is the same problem in web-apps, stored procedures, distributed systems, mobile apps, main-frame software, and client/server.

You will probably need to invest in significant refactoring to enable unit-testing. If all your existing code is already in a structure that is easily unit-testable => Praise yourself lucky.

EXAMPLE: ItemChanged on DataWindow control in a window with embedded SQL => Mix-up of user-interface, business-logic, and data persistence.

EXAMPLE: Clicked on menu item gets data from one window, calls response window; then takes results from that response window and updated the a third window. The response window itself uses DataWindows and embedded SQL to process data. It also imports data from a text file and validates that data. => Again mix of every layer and interface imaginable.

How do you unit-test that when you fix a null object reference? It is SO HARD to start unit-testing such code. Not because code is faulty. Not because PowerScript or DataWindow is bad. No, it is caused by testability not being a focus when code was originally written.

I ALWAYS encourage a "think testing/usage first" mentality. But it may be costly to enable unit-testing due to existing code base.

HTH /Michael