-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test input_select, wrong idea? #48
Comments
@FlorianKempenich sorry for the push, Thank you |
Hi Andy, I'm really glad you find our tool useful 😃 You might not be a python guru, but your code is very readable, it made it easy for me to follow what's happening 💯👍 Regarding the issue, may I ask:
Best, |
Was the problem caused by having |
Hi Florian, yes, the problem is caused by the fact that select_option is not being mocked. The PR is solving for me the mocking part. Please before closing the issue let me work on it for a while. If I can, I would like to propose a complete solution for it. I may need your advice on the testing part and the implementation of the assert_that part. It seems a bit obscure to me what is happening there. thank you |
Haha yeah . . . If I'm being honest . . . it is a bit obscure what's happening here. When I first implemented this I favored readability of the test utility rather than the implementation. The tests ensure that it works as expected, but yes, the implementation is a bit cumbersome. The easiest way to contribute to this part is to go TDD:
If the test pass, you know you've got it. Once the test pass, then try and see if you can refactor things to make it a bit more readable. That way: You first have something that's proven to work, then you can make it look a bit more clean now that you understand how it work, and you don't have to worry about adding a test because it's already there 😁 I'll keep the issue open until the PR is merged 🙂 Take your time, there's absolutely no rush. And don't hesitate to ask questions, I'll answer asap but that might mean a couple of days :) |
Hey 👋 For now, you can consider this project unmaintained, unfortunately. I haven't had time to maintain this repo in the last few years, in good parts because I moved home and I haven't had a HomeAssistant setup for a very long time. So I'm a bit disconnected with the latest updates, and it's a huge overhead to start everything again, get context and understand how to fix issues on this project However, I've finally taken the task to set up my server at home again, so I'll probably use this project for my own use again soon. This means I may bring this project up-to-date in the next few months. No guarantees, obviously, but I may. Best, |
Hi!
Thank you for this amazing piece of software. I am not a python guru but I used a lot appdaemon in the past.
I am starting with a different approach about how to use appdaemon and home assistant.
Basically I am splitting my "big classes" in small modules and everything is going to be saved in home assistant entities. This is now really easy because the helpers entities can be added directly in the front end.
Based on this, I have small classes that sets different partial config states. This is really helpful in order to debug the current state and adding some test to the class is straightforward.
I am facing with a doubt that I cannot solve alone.
I am rewriting the noone, someone, everyone status in appdaemon because the way appdaemon uses it, or how home assistant define the home/away does not suit my needs.
In order to re-implement it I am using an input_select with defined states.
My class is changing this status based on device_trackers.
and this is the relevant part of the class:
And now the question:
I don't find any way to check if select_option sets the right status. It seems that at the moment the select_option call is not wrapped. Running the test I see in the error message:
Am I missing something obvious here?
Thank you in advance
Andrea
The text was updated successfully, but these errors were encountered: