| 2011-09-20 22:30:32 utc | pbh_ | hey, has anyone used ruote-on-rails? |
| 2011-09-21 23:32:14 utc | jmettraux | pbh_: hello, do you have an issue with ruote-on-rail ? If nobody is replying here, feel free to post on the mailing list (http://groups.google.com/group/openwferu-users) or fill an issue report (https://github.com/tosch/ruote-on-rails/issues) |
| 2011-09-21 23:44:30 utc | pbh_ | hey there |
| 2011-09-21 23:44:53 utc | pbh_ | no issue, i was just a little confused as to the goal of the ruote-on-rails app |
| 2011-09-21 23:45:10 utc | pbh_ | since it seems very similar to the default functionality of ruote-kit |
| 2011-09-21 23:45:18 utc | jmettraux | OK. Well it's an example |
| 2011-09-21 23:45:49 utc | pbh_ | but with a few modifications (forms via quaderno etc) |
| 2011-09-21 23:46:51 utc | pbh_ | my other question is what the state of ruote testing is |
| 2011-09-21 23:47:21 utc | pbh_ | the documentation just says "TODO", and i can't tell whether that means that there's easy test::unit support existing but not documented, or whether that means the support itself is TODO ;-) |
| 2011-09-21 23:47:51 utc | pbh_ | (though the existing documentation is quite helpful) |
| 2011-09-21 23:50:06 utc | jmettraux | OK, I should replace that TODO with something consistent |
| 2011-09-21 23:50:17 utc | jmettraux | rspec and test/unit examples |
| 2011-09-21 23:51:54 utc | pbh_ | (i did notice that ruote-cukes seems to exist) |
| 2011-09-21 23:52:12 utc | pbh_ | are there any asserts, like assert_transitions_to_participant or something? |
| 2011-09-21 23:58:32 utc | jmettraux | no, nothing like that |
| 2011-09-21 23:59:23 utc | jmettraux | the only useful thing is Engine#wait_for(x) |
| 2011-09-22 00:00:06 utc | jmettraux | where x can be a String (wfid (workflow identifier)), a Symbol (name of a participant), or an integer (number of workflow actions/msgs) |
| 2011-09-22 00:00:06 utc | pbh_ | ah |
| 2011-09-22 00:00:38 utc | pbh_ | ah, so if you want to test whether a workflow transitions to the right participant |
| 2011-09-22 00:00:42 utc | pbh_ | you could wait_for(1) |
| 2011-09-22 00:00:53 utc | jmettraux | not really |
| 2011-09-22 00:01:15 utc | jmettraux | these are not "steps", they are "workflow messages processed" |
| 2011-09-22 00:01:31 utc | pbh_ | ah, and it might be the case that there's some nonstandard number of replies or dispatches or the like? |
| 2011-09-22 00:01:49 utc | jmettraux | Ruote.define { alpha } |
| 2011-09-22 00:01:58 utc | jmettraux | will take 3 msgs to reach alpha |
| 2011-09-22 00:02:17 utc | jmettraux | launch/apply workflow, then apply participant expression, then dispatch to alpha |
| 2011-09-22 00:02:30 utc | jmettraux | engine.wait_for(:alpha) is probably what you want |
| 2011-09-22 00:02:55 utc | jmettraux | example using engine.wait_for(wfid) (String): https://github.com/jmettraux/ruote/blob/master/test/functional/ft_70_take_and_discard_attributes.rb |
| 2011-09-22 00:03:15 utc | pbh_ | does wait_for have a timeout or anything? |
| 2011-09-22 00:03:51 utc | pbh_ | e.g., what happens in ruote-cukes when there is no transition to alpha and you do " Then the process should reach alpha" or when you do a wait_for and alpha is never transitioned to? |
| 2011-09-22 00:04:03 utc | pbh_ | does it just wait forever? |
| 2011-09-22 00:04:07 utc | jmettraux | yes |
| 2011-09-22 00:04:29 utc | jmettraux | for my ci needs I wrap the whole in a timeout |
| 2011-09-22 00:05:36 utc | pbh_ | ah, do you wrap each test or the full test suite with a timeout? |
| 2011-09-22 00:06:16 utc | pbh_ | (and do you have a gist and/or github link as to what that looks like?) |
| 2011-09-22 00:06:30 utc | jmettraux | http://ruote-ci.s3.amazonaws.com/ci.html |
| 2011-09-22 00:06:38 utc | jmettraux | https://github.com/jmettraux/ci |
| 2011-09-22 00:07:16 utc | jmettraux | in "ci" I'm simply using the ruby timeout stdlib thinggy |
| 2011-09-22 00:07:41 utc | jmettraux | having the timeout specified when calling wait_for might be a good idea |
| 2011-09-22 00:08:12 utc | pbh_ | i think you're probably right not to build it in |
| 2011-09-22 00:08:55 utc | pbh_ | it seems like the more natural fix is to have a hook for when a participant transitions or a message occurs or what have you |
| 2011-09-22 00:10:22 utc | pbh_ | (and in the meantime wrapping the wait_for call with a standard ruby timeout seems easy and robust enough, as long as you're not dealing with underlying storage that is prone to super long timeouts or anything) |
| 2011-09-22 00:11:20 utc | jmettraux | true |