I’m not sure I really get the point of the macro: is it to disable unit tests for the framework, or disable using unit test related classes and functionality altogether?
Right now, with that macro set to a disabled state, I haven’t access to the unit test categories.
Thing is, I don’t care to build and run JUCE’s unit tests - I only care about my own.
In my opinion it would be useful to open the header up for public use.
unit_tests/juce_UnitTestCategories.h defines several strings that are used by JUCE’s own unit tests. I don’t think they are meant to be used outside of JUCE itself.
Well, having precreated categories for everybody to use the same sounds like value added to me… Why hide it away like it’s some LOTR ring?
By defining the
JUCE_UNIT_TESTS macro you activate the unit tests to be RUN. So you don’t want to run the unit tests in your project, since that would mean, the test runs on the users machine.
You can create your own project with the macro defined to run the unit tests yourself to see, if anything in JUCE is broken.
Or alternatively just add a configuration that specifies the macro, so you can build and run that target to run the tests inside your project.
And you can add your own tests using the same method, in which case it would make sense to automate the unit tests on your machine as well.
But afaik the unit tests are run on the JUCE teams CI server, so normally no change is pushed, when the unit tests haven’t passed (that’s what they tell, I am no insider).
Erm… no. The macro simply compiles in the unit tests - and subsequently includes the categories - which in turn adds the unit tests to a global list of unit tests that may be run at any time. It’s up to us users to set up a
UnitTestRunner to run them at our convenience!
I’m familiar with the process and all of the underlying structures - my initial argument still stands, in that having the precreated list of categories would be a nice-to-have, regardless of the state of the said macro in the title.