Using NIT (NUT Integration Test suite) sandbox

As with any other well-behaved code base, when building NUT from source, it is possible to make check the program and resource files (e.g. documentation).

One special feature of NUT v2.8.x is that you can make check-NIT to run the NUT Integration Tests with upsd talking to some dummy-ups instances and different scenarios such as about having and not having configuration files, as well as testing the Python/C++/etc. client implementations (if enabled). This is the same scenario that NUT CI farm runs on various platforms to detect significant regressions in core code/behaviors, as well as to help with porting NUT to new OS platforms and tool sets.

Notably, the NIT suite would run your freshly built NUT programs (right from the build workspace) with a dedicated temporary configuration and state directory, and communicate on a random TCP/IP port, so should not conflict with the normally running NUT daemons which monitor your actual UPS.

With make check-NIT-sandbox you can further prepare an environment to run other built NUT programs against these upsd + dummy-ups, or to edit the generated config files in tests/NIT/tmp/etc/ directory and e.g. test a freshly built drivers/usbhid-ups program. The sandbox initialization will log some progress and ultimately suggest you to source a generated NIT.env file with environment variables for the random $NUT_PORT, NUT user names and passwords, configuration paths and stuff, etc. into your current shell.

• NOTE: Currently for NUT client programs, including nut-scanner and dummy-ups, you would have to also export LD_LIBRARY_PATH_CLIENT="${TOP_BUILDDIR}/clients:${TOP_BUILDDIR}/clients/.libs" with your definition of TOP_BUILDDIR, to use the freshly built libupsclient.so file and not the system-installed one.

Note that depending on tooling, your actual libraries and programs may be in .libs sub-directories, so e.g. drivers/.libs/usbhid-ups and the filenames near the sources being GNU libtool wrappers to set up paths and debugging. For tracing or gdb stepping, you need the actual binaries (and manually reproduce the path setup that libtool does).

• it might work or not to try forking support (so the debugger does start the wrapper script and then does see the actual NUT program) - I did not have much success in that generally.