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

pybokeh pybokeh at gmail.com
Wed Feb 6 05:42:29 EST 2019


Joshua, maybe Travis us right.  If you're interested in a task scheduling
framework, there's Apache Airflow (
https://github.com/apache/airflow/blob/master/README.md).  It is a bit of a
heavy framework.  If you don't need to necessarily schedule tasks at
certain times or intervals, but just execute tasks based on execution of
other tasks, there's Luigi (
https://github.com/spotify/luigi/blob/master/README.rst).  I use Luigi at
work for running data processing tasks, but tasks can be any Python
function.  Here's a relatively short video on it:
https://m.youtube.com/watch?v=TYtHzvys33A

If you want a lighter framework, there's bonobo (
https://www.bonobo-project.org).  Even though it is geared for data
processing tasks or ETL, I believe it can be used for executing regular
Python functions also.

On Tue, Feb 5, 2019, 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/20190206/e1caea41/attachment.html>


More information about the CentralOH mailing list