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

[Max]

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>
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> 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>
> 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
> >> https://mail.python.org/mailman/listinfo/centraloh
> >
> > _______________________________________________
> > CentralOH mailing list
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/centraloh/attachments/20190205/5c17849c/attachment-0001.html>