I have built most of my automations with appdaemon apps, the problem I have is not so much with appdaemon but with python itself.
I am used to working with a compiled language that has static typing, python is (afaik) none of those.
So when doing rewrites of my automations or adding new functionality i sometimes end up braking my system in a way that I don’t notice it until that particular pice of code runs (usually right before i go to bed for some reason). Errors that to 99% would be catched by a compiler at compile time.
I am not a python developer by trade, so is there something i am missing?
How do other people handle this?
On the top of my head I can think of a few ways:
Manually run through all thinkable scenarios when making larger changes.
I guess it comes down to experience and test coverage - instead of testing the condition when you go to bed, use the developer tools to force the state changes so you can test it there and then - I do that for a lot of my automations.
dont make big changes to running, important code all at once, but save in between.
after every save check your error log.
i have the "normal"log always on screen, so when i save i see immediatly when the app starts up as it should.
so at least i know that i have no errors that prevent the code from running.
off course i sometimes use vars that are not valid at that point, but most of the time only in new code.
and when a new piece of code breaks, ah well no big deal its not an automation i already rely on.
if it is possible i use another trigger to check if i got it correct (if an automation only runs once a day, or on times i dont want to check for instance)
in stead of a listen state from a motion sensor far away, i use one that is near, i change the time, etc.
I do have windows open with error log and the normal log, and during the actual development I think the workflow is as good as it gets with this kind of setup.
(It’s much much better than domoticz that i used to run)
The problem is with the errors that occur in the special cases and when certain conditions are met.
Sure, I could probably try to force more state changes manually when testing, I do that for the most common cases now but not for everything.
I guess I am spoiled (or whatever you would call it) being used to a compiled language with stricter type checking, and most of the errors I find in my python appdaemon app development (when I don’t want to find them) are simple spelling errors/syntax errors and stuff like that, it just seems unnecessary waste of time not being able to do some sort of compile/static code analysis to catch those before runtime.
I would suggest you take a look at a full IDE like PyCharm - among many other things, it will highlight things like misspelled variable names etc. while you are editing, and would go a long way toward bridging the gap between compiled and interpreted languages.
Just wanted to provide an update.
I have been using emacs for a long time and will probably stick with that for the time being.
Running flycheck with pylint in emacs made the process a whole lot better, it’s remarkably good at picking up on errors.