Hello stevieb,

Having finally taken a look at App::RPi::EnvUI, I was able to come up with the following high-level thoughts:

• Testing the method requires many preconditions/dependencies;

  Your application requires modules that make no sense without a Pi. However, the UI and DB parts are pretty much decoupled from that, so I'd say one could try to resort to mock when the real thing cannot be loaded. This would simplify trying the UI out before uploading to a real thing as well as developing it.

  Design-by-Contract may be useful here to verify that the module being loaded is actually matching the expected interface. This part of Assert::Refute is far from perfect for now, so let's pretend runtime assertions are a form of contract.

• The method includes side effects and outside world interactions that are not easily replaced with mocks;

  Did turn fan off call actually turn fan off? Well, you can't tell for sure unless you see the fan with your eyes. But at least you can check with extra calls wrapped in refute_these{ ... } blocks that the system remains consistent from within. And of course there's good old if (DEBUG); or shiny new Keyword::DEVELOPMENT to minimize performance hit.

• The method only misbehaves sporadically, doing what it should do most of the time, and the exact conditions required are not known;

  Maybe not exactly this case, but how about some sanity checks for temperature sensors?

  use Assert::Refute::T::Numeric;
  
  refute_these {
      is_between( $temperature, 50, 140, "Temperature is sane" );
  };
  [download]

  At least if thermometer breaks and starts sending 0s, you notice it before the greenhouse boils.

• The method needs to be refactored to be properly tested, and needs test coverage to be refactored.

  Not applicable to specific app because it's done with tests to begin with. However, my other replies must shed some light on that particular use case.

Thanks again for your inquiry, it was quite insightful.