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
Simple stylistic changes to APIs make functions, events, and even full classes far easier to unit test.
Stay tuned.