Maureen:

For what it's worth, I do some kind of unit testing using uopy.

If you are writing some UP call UP_TO_TEST you can read it like this

    with uopy.connect(host='...', user='...', password='...', account='...') as session:
        with uopy.File('UP') as file:
            up_code = file.read('UP_TO_TEST')

Then you can parse its arguments from the header

SUBROUTINE UP_TO_TEST(A, B, C, D)

Then you can compose a Python string with all the tests that you need

        test_code = (f'A={python_var_1}\\r\\n'
                     f'B={python_var_2}\\r\\n'
                     f'C={python_var_3}\\r\\n'
                     f'D={python_var_4}\\r\\n'
                     f'RETURN.VALUE=CALL UP_TO_TEST(A, B, C, D)\\r\\n'
                     f'CRT:RETURN.VALUE\\r\\n')

Once you have all your test code you can convert it into a DynArray

        code_as_dynarray = uopy.DynArray(test_code)

With uopy you can upload the code, compile and catalog it and then run it.

    with uopy.connect(host='...', user='...', password='...', account='...') as session:
        with uopy.File('UP') as file:
            rec = file.write('UNIT_TEST_FOR_UP', code_as_dynarray)
        compilar = "BASIC UP %s" % 'UNIT_TEST_FOR_UP'
        catalogar = "CATALOG UP %s" % 'UNIT_TEST_FOR_UP'
        c = uopy.Command(compilar)
        c.run()
        c = uopy.Command(catalogar)
        c.run()
        ejecutar = "RUN UP %s" % 'UNIT_TEST_FOR_UP'
        c = uopy.Command(ejecutar )
        c.run()
        print(c.response)
    

I know, it's quite cumbersome but from here you can parse the output and then make full use of the built-in Python unit testing framework.

Hi Maureen

I have developed using, and taught clients to use, test driven and test supported development for UniVerse. There are differences in patterns between UniVerse / MultiValue approaches and more class-oriented environments, but the same concepts can be applied. Unit, happy path, regression and volume testing can all be built into your applications and development cycle  - though not always with ease if they are not designed for testability :)

It is definitely worth the effort, and improves not only code quality but communication of what the code is intended to achieve.

Check out mvTest on my website (www.mvdeveloper.com) if you are interested in learning more.  I wrote it because none of the testing tools available at the time really handled all the specifics of working with UniVerse, and I wanted to improve my own software. This has a testing language modelled on UniVerse Basic but with extensions specific to testing - including a good suite of assertions, testing-specific functions, handling profiles and test data - and test recorders for scripted regression tests. 

Brian

During years of developing my tool sets, I would build test programs that would call routines with parameters, compare expected and actual values, and display failures.

Then I broke down and wrote a framework library that would drive tests, provided a library of Assert routines that would log failures with locations, display results with which assert failed, and if you needed to edit the test would launch an editor (vi or ED so far) positioned to the failing Assert call. It made my life easier. It even has documentation!

If you would like to see it, you can contact me.

Thanks Héctor,

We are not using uopy but will keep this in mind if we do go down this path.

cheers

Maureen

Thanks Brian and Mark,

Your tools sound really interesting. I forgot to mention we run Universe on Unix (Solaris). Do your tools work with this OS?

Hi Maureen

Yes, it's all client/server so each test run opens a new session to ensure a clean environment, or multiple sessions if you want to do performance or multi-user testing for (locks etc.). There is a CI implementation that works similarly and can be tied into a regular CI platform, and a server side only one that useful if you need to catch issues in the UniVerse debugger or any error messages that might get thrown up (or the client/server can COMO). So lots of options!

I've also added in some nascent python testing support as the rewiring that UniVerse does for Python routines that are called from UniBasic (calling out, not calling in) scrambles a lot of the regular python unit testing tools and they, of course, are not aware of the environment for setting up and tearing down test data, mocking and faking calls etc.

Brian

Brian, first of all thanks for all you do on the various forums and mailing lists, and blog posts at mvdeveloper.com - it's really appreciated!

Have you thought about releasing your course training course "Test Driven Development with mvTest" as an eBook, perhaps with a single user version of mvTest?  That would be one way to capture a part of the solo-dev market (not sure how big that market actually is, but at least one :).  Or if you have videos of previous courses for a subscription fee on Youtube?

The thing I'm struggling with is getting started with TDD conceptually - 80% of the programs I deal with are variations of "read stuff in, process, write stuff out", where the direction could be in or out of the MV system.  Mocking the data seems like a monumental task, and once the program is in production most errors come from bad data or environmental problems, not logic errors (the logic is usually not that complicated).

Ian, it's a good thought! Like everything else it comes down to time - writing eBooks (well) takes a lot of that and right now it's a limited commodity - but I will see what I can do.

Brian