Replies: 2 comments
-
I am always open to new ways of doing things. At once point I did have rspec tests in place. But for unit testing shouldn't we be mocking out OH not running OH. I have been using cucumber as BDD, not as unit testing. I think there is room for both. However, I did find when I was doing both unit testing and BDD testing that the unit testing ended up being unnecessary because the BDD (outside in) tests were covering it. So the unit tests would need to cover places where we have pure logic in ruby with no need to test the interactions from the language itself. Do we have a lot of places that we encounter that? Even in the case you point out (comparisons), there was work needed to validate conversion of units was working in the DSL. |
Beta Was this translation helpful? Give feedback.
-
I think you're missing the premise here. I'm less concerned with how the tests (and you can argue the intricacies of BDD vs. unit testing all you want) are written, and more wanting to switch how OpenHAB is spun up to not require so much of OpenHAB to load, be forced to control it by spawning separate processes (karat), have to wait and guess when OpenHAB loads a rule file, have the only communication back to the testing process be tailing logs, etc. I simply mentioned rspec as a possibility to gauge interest if we're going to the work of re-architecting the test infrastructure anyway. |
Beta Was this translation helpful? Give feedback.
-
What are peoples thoughts on taking unit testing for this gem a slightly different direction? Are you married to cucumber, @boc-tothefuture? I'm have really good success with my https://github.com/ccutrer/rspec-openhab-scripting gem's model of having JRuby be the boot up process, and then running a subset of OpenHAB inside of that process without any threading. It's waaaaay faster to run tests this way. It's not a perfect analogue for a true OpenHAB instance, and doesn't actually use the org.openhab.automation.jrubyscripting bundle at all (it's unnecessary since JRuby is already active in the process), so I still think we should keep some subset of the current Cucumber tests around. But many tests could be written with this new model completely safely. Think of the comparisons.feature. Basically anything not having to do with how rules are loaded from the file system (or UI), or not testing the complete stack of OpenHAB hooks into the automation bundle (like scriptUnloaded). And in general pure rubyists (ok, me) are much more familiar and productive with RSpec rather than Cucumber, which comes more from the Java world.
Beta Was this translation helpful? Give feedback.
All reactions