XojoUnit

General
1

This looked interesting when discussed in Paul’s 2019 presentation, and I am left with some questions:

  1. I have been creating small test projects to test a number of my methods, typically one per small project; presumably the concept here is, instead, to include XojoUnit in one’s project and do all the tests there instead. How can I arrange to exclude all this code from a distribution version of my app? I can choose different settings for Stage Code inside the Shared Build Settings, but how can I test against that at compile time?

  2. The docs for this seem quite old and I could only see my tests being run when including this

group = New MyTests(Self, "My Tests")

in the InitializeTestGroups event handler for the DesktopTestController class, rather than subclassing TestController and putting it there. Is this the right thing for 6.6?

  1. I assume also that I can toss the entire Tests folder and also remove initialisation for those tests from InitializeTestGroups?

  2. Am I right in thinking that XojoUnit is intended for cases where a method takes some input and returns a value? Most of my more complex methods tend to send/get data to.from sockets or fiddle with the UI. Up to now I’ve used the Mk 2 eyeball for this purpose.

2

  1. You want to exclude just the tests or the entire framework? (I’m puzzled why you’d need either though.)

  2. Yes. In my projects I move DesktopTestController out of the main folder and initialize tests there. When I replace the package, I remove the DesktopTestController1 that appears.

Eventually I’m going to include a “Register” function so this will no longer be needed at all.

  1. Yes, but as they will be copied back when I update the package, I usually don’t bother, I just comment out the lines that initialize those.

  2. It can be used for a variety of purposes, including timing, as long as you can test that the result is what you expected. Sometimes this is just making sure that an Exception is raised, or not, and in some cases a simple Assert.Pass will do. For sockets, etc., you can use the Async functions to test that a result has been received and is what you expect.

Fiddling with the UI is not something I’ve tried, but for testing private functions that you prefer not to make public, I create a special UnitTestClassInterface that can be assigned to object and that will let you test independently.

3

I’d like to be able to exclude both.

4

If you surround your calls to the framework in pragmas linked to a constant, the compiler should exclude those classes. I think.

But I can’t think of a formal way to force that.

5

Well, ultimately I guess it’s not a big deal. I suppose I could exclude the classes from the build, but that’s all a bit manual.

Humph. Then it doesn’t compile.