Xojo apps and Unit Tests

1

I only came across this concept recently. Let me see if I have it right: if I want to test some portion of my app, I can have (say) a window where I can load up some dummy data and press a button to run it and get results showing success/failure. This will be built into my app so I’m always testing against production software rather than in a separate testbed which I then have to remember to update along with the app if I change it. Am I right so far?

Additionally, I assume I don’t want to have this code cluttering up the production version that is distributed to users, so I further assume that this is done as a debug build and conditionally compiled in. Should I further be creating the window and other controls at runtime rather than just adding them with the IDE? I’ve not noticed any way to have controls be conditionally added to a layout in the IDE, but perhaps I’ve overlooked some feature here. What’s the best way to keep all this separate from the production side of the app?

2

  1. write as much code in method that can be tested independently of a UI
    This will make it so you can test a LOT of your app without a UI (a good thing)

  2. wrap unit tests in #if YOUROWNCONSTANT that is set TRUE for debugbuilds and FALSE for release builds
    This way they get stripped from production runs
    This is usually a good thing UNLESS you need to enable them for a production run(which is sometime necessary) and if you just used DEBUGBUILD you will have a bugger of a time finding them all

  3. testing UI automatically is truly a pain

As for how to have a UI that is only included in a debug build what you CAN do is

  1. in your unit tests wrap the dim s as MyUnitTestWindow in #if so it gets stripped from production runs
  2. turn OFF implicit instance for this window
    that way its never referenced in a production build and so it will be stripped out

I can’t think of any other tidbits of advice at the moment

I’m sure others will have their own

3

Unit Testing is for the non-UI part of your software. If you have an algorithm then unit testing makes sense. For the UI it doesn’t make sense at all.

4

It might make sense but the abilities to DO it are mostly missing (sadly)

MPW used to have a means to write UI test scripts that Applescript could sort of do if yor app was really scriptable
You could write a script that tested the ui
see http://preserve.mactech.com/articles/mactech/Vol.12/12.09/UsingVirtualUser/index.html

I suppose a really scriptable app could use Applescript and then run tests that way

Most others are screen recorders and just compare pixel by pixel pictures to know if they got the right result
I havent seen a lot of others

5

Thanks both. That more or less agrees with the mental picture I had arrived at, but it’s always useful to have it confirmed.