Sha256: 04b62a94269121be39ff1068c985927dd3b909d2f1f8fa5e267a8ded7aeb98c7
Contents?: true
Size: 1.8 KB
Versions: 1
Compression:
Stored size: 1.8 KB
Contents
Botfly Todo List (by priority) ============================== * Have Bot.new and Bot#run instead of just #login that always runs * Write cucumber integration testes * Replace CommonBlockAcceptor responder chain array with ResponderChain object ** Spec & create ResponderChain class ** Have responder chain stop call first responder ONLY after reaching a match ** Additionally provide DSL for on... chain to give priority to responders (that is to say one can specify which responders fire first) * Finish speccing matchers, responders * More robust instance methods on responders (i.e. provide access to variables through methods and not ivars) -> In fact, the base Responder class should, for each parameter, set up a set of default instance methods for each parameter (since, largely, these parameters are standard across their names) This will DRY up the "setup_instance_variables" as that paradigm performs horribly in flog and other stats * Additional matchers on single and multi-user chat (not sure what, but doesn't feel complete) * Add configure method to accept list of configuration paramaters. * Support any of a bevy of features provided by xmpp4r Unsorted ======== * Some sort of xmpp4r mock/helper to more easily test external services I'm imagining skipping most of the xml junk that goes on internally in xmpp4r. Something maybe like this: it "should reply 'yo!' to any message" do bot = Botfly.new("doesn't", "matter") do on.message do reply "yo!" end on.subscription_request { accept } end bot.should receive(:message, :from => 'jim@someserver.com/home', :message => "Hi!"). then reply_with "yo!" # A full range of starting custom matchers (get, be_added_by, something, etc.) and set of response matcher end
Version data entries
1 entries across 1 versions & 1 rubygems
Version | Path |
---|---|
botfly-0.3.6 | TODO |