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?
-
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)
-
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
-
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
- in your unit tests wrap the dim s as MyUnitTestWindow in #if so it gets stripped from production runs
- 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
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.
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
Thanks both. That more or less agrees with the mental picture I had arrived at, but it’s always useful to have it confirmed.
I am now reading the unit testing possibilites in Freebasic. This wiki Document was written in 2011
https://www.freebasic.net/wiki/DevFbcTestSuite
It’s unbelievable, what if Xojo would develop an integrated unit testing module or Praeprocessor in its IDE back in those time. So much wasted opportunities…
Yeah. With my multiple years in Go I’ve been amazed at the built-in unit testing. I would have killed for this in Xojo. And no, XojoUnit is not good enough - we’ve tried using it several times without good results.
I’m sure Dear Leader has no idea why this is important. But then again, the types of developers that want and need unit testing aren’t the type of developers he’s aiming for. So…advanced topic!
1 Like
That’s always the case when the target is only hobbyists with no requirements in professional programming. They don’t need it. The professional programmers are in a hurry to get unit tests but the company says: no. Or maybe. Or coming soon. Builds then something what sounds like it could be but…no. And this is the eternal circle you will run along with Xojo. It will never change while they can’t see things like this. But there is another point: GO is - like Java - free. That means in the same moment: they want to be on top. So they do what ever they can do to bring it on top. Xojo is not willing to do it. While they have no sponsoring culture and no open Source culture. If there would be an open source cli compiler like for Java, Go, c++…this would be different while nobody is in the need to build with this old style IDE but with a better one. So it would come to a completely different behavior of the professional programmers. But not being able to correct bugs and showstoppers and not to be able to speak with them about makes it impossible to use. That’s why you use GO and not Xojo for your Jobs. Cause you need to get your Job done. And when ever you pull a bugfix for Go compiler they will look on it and take it to push that to their sourcecode if it makes sense. And that will at Xojo never be happened. I by self have some problems with JavaFX, believe me. But I am pushing than Bugfixes and they will be done by the JavaFX development Team at GluonHQ or at Oracle. So bugfixing works withput any problem.
With Xojo you have one problem. Bugfixes are impossible. While you need to report the Bug but they are setting them on Review and often archiving them later. Without even really looking on it.
Looks like that edit got added quite some time ago
Its present as far back as 2019
XojoUnit is not my favourite and I avoid it
XojoUnit is not user friendly in many ways.
