[CentralOH] Most "Pythonic" way to accomplish this?

[Travis Risner]

Hi Joshua,

If I understand your intent, you are not interested in mocking anything. 
  Instead, you want to periodically run some tasks on something external 
to Python.

Given that assumption, if I were wanting to accomplish this, I would 
look for a framework or library that would let me do the following:

*  Schedule running the task in a way that is external to the task.

*  Let the task report the results in a stratified way (e.g. like HTML 
response code) so that I could specify -- external to the task -- what 
subsequent action to take.

*  Allow the tasks to run either asynchronously or as a series of 
sequential tasks if that is necessary.

Maybe another way of thinking about this it to let the data drive the 
activity rather than baking the scheduling, reporting, and/or subsequent 
action into the code.  I would pull all of the things that might change 
out of the code so frequency of testing, action to take based on results 
of the test, etc. can be easily managed with a GUI or an easily modified 
configuration file or table.

HTH,
Travis

Max wrote:
> Let's say you have logic like:
>
> if isMotorToHot:
> checkCoolingValveOpen
>
> You can easily mock the isMotorToHot function to return True or False
> (assuming it returns a bool) using the mock library. Then, you can
> check to see if the function has been called. Ideally, you want a test
> for Both of these come really easy through mock and pytest without any
> dependency on the hardware. That way, you're isolating your test to
> just see the flow through the conditional logic. Structuring this way
> allows you to skip calling the actual device code (as you just need to
> see if the fxn is called) and run a separate pytest suite for things
> that directly interact with the device and may or may not be god-awful
> slow due to the mechanical nature of real life.
>
> On Tue, Feb 5, 2019 at 2:01 PM Joshua Kramer <joskra42.list at gmail.com
> <mailto:joskra42.list at gmail.com>> wrote:
>
> Hi Max, I'm not sure I'm understanding you correctly. It seems that
> the example you provided will test that the function "isMotorTooHot()"
> works as intended- a unit test on the function isMotorTooHot. That's
> not my intent. For this particular example, I want to call a function
> that will determine if the motor is too hot. If the motor IS too hot,
> I then want to call a function that will check to see if the cooling
> valve is open
>
> Unit testing to determine whether or not the various functions
> (isMotorTooHot, isCoolingValveOpen, etc) return correct values based
> on physical attributes is not within the purview of this specific
> example- that will be handled elsewhere. My goal is to write a
> framework that I can use to run arbitrary sets of tests for specific
> conditions in the environment, not within a class or other bit of
> Python code.
>
> On Tue, Feb 5, 2019 at 1:08 PM Max <kedlav at gmail.com
> <mailto:kedlav at gmail.com>> wrote:
> >
> > Generally speaking, it's strongly discouraged to structure tests
> in this way where you have conditional logic baked into the test.
> Instead, you'd want to setup individual tests covering scenarios.
> >
> > Base State: Motor running
> > Test 1:
> > 1.) Call function
> > 2.) mock return of temperature below 'too hot'
> > 3.) assert that the correct behavior has occurred.
> >
> > Test 2:
> > 1.) Call function
> > 2.) mock return of temperature below 'too hot'
> > 3.) assert that the isCoolingValveOpen function was called
> >
> > Test 3:
> > Unit tests to cover isCoolingValveOpen does what it is supposed
> to do.
> >
> > On Tue, Feb 5, 2019 at 12:14 PM Joshua Kramer
> <joskra42.list at gmail.com <mailto:joskra42.list at gmail.com>> wrote:
> >>
> >> Thanks Zak! I should clarify that with this particular
> question, I am
> >> not writing tests for code. For failures, Pytest gives a lot of
> >> information about the code, which would not apply in my case. For
> >> example, I might want to run some hardware tests. The runTest
> method
> >> in myTest1 object might run a function called "isMotorTooHot()", and
> >> if that returns true, then the next test in the list would run
> >> "isCoolingValveOpen()", etc. So perhaps we should think of these as
> >> "tasks" instead of "tests".
> >> _______________________________________________
> >> CentralOH mailing list
> >> CentralOH at python.org <mailto:CentralOH at python.org>
> >> https://mail.python.org/mailman/listinfo/centraloh
> >
> > _______________________________________________
> > CentralOH mailing list
> > CentralOH at python.org <mailto:CentralOH at python.org>
> > https://mail.python.org/mailman/listinfo/centraloh
> _______________________________________________
> CentralOH mailing list
> CentralOH at python.org <mailto:CentralOH at python.org>
> https://mail.python.org/mailman/listinfo/centraloh
>
> _______________________________________________
> CentralOH mailing list
> CentralOH at python.org
> https://mail.python.org/mailman/listinfo/centraloh

-- Sent by Travis Risner