Botkit: integrate botkit-mock

[amplicity]

Leaving this task open for PRs/comments relating to integrating https://github.com/gratifyguy/botkit-mock into botkit.

[colestrode]

This project looks really awesome 😄 It sounds like this would help Botkit developers by providing them some mocks they could use to write their own integration tests for their Botkit bots?

[amplicity]

Yes. You can accomplish that now by installing botkit-mock separately (npm install botkit-mock), but this integration will negate that requirement and give botkit unit-testing functionality out of box.
On Mon, May 22, 2017 at 2:39 PM Cole Furfaro-Strode <
[email protected]> wrote:

This project looks really awesome 😄 It sounds like this would help
Botkit developers by providing them some mocks they could use to write
their own integration tests for their Botkit bots?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/howdyai/botkit/issues/850#issuecomment-303184963, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACKLHuEc0c1qLmHXElRJnkBQq8HCtH2Cks5r8dZwgaJpZM4NfMlF
.

[amplicity]

@benbrown @peterswimm with respect to @colestrode's PR that got merged for unit-testing. Do we want to integrate botkit-mock from an integration-testing perspective now?

ie..

1. dev installs botkit dependency
   2a. dev can perform unit-testing [test botkit's core code] out of box (using @colestrode's PR)
   2b. dev can perform integration-testing [test dev implementation of botkit] out of box (using to-be-created botkit-mock PR)

Thoughts?

[peterswimm]

@amplicity That sounds about right, botkit-mock would end up becoming a dependency, and a developer could use either!

[colestrode]

I'm trying to put myself in a user's head for using this mock from within Botkit. One challenge I see for a user of Botkit is that it seems the mock is opinionated on how they set up their controllers. By this I mean: they need to attach their event listeners to their controller in module that exposes a function to accept a controller. For example:

module.exports = function testable(controller) {
  controller.hears(....);

  controller.on(...);
};

That is a useful pattern but not the only one that people will use (here's a very simple example of not following the module pattern). I'm wondering if there is a way that the mock could just wholesale replace the low-level behavior of Botkit, maybe with an environment variable, without needing users to write their code in a specific way. I think as a standalone library it's fine to impose some design to do testing, but once it's part of the core library it seems it would be nice to support an array of designs and use cases.

[benbrown]

@colestrode ah! interesting point.

[amplicity]

@colestrode thanks for bringing this up, hadn't seen this case. Will look into how we can accommodate multiple coding styles.

I do think, as a whole, we should continue to integrate botkit-mock for integrated testing. Even with botkit-mock available as a third party dependency, many developers still ask and search for this functionality. This would cut down on any time a dev would spend questioning/finding an integrated test solution.

With that said, I think it should be integrated with support for any style of coding that botkit supports. I will cycle back with feedback on how we can support any style of botkit coding practice.

[amplicity]

I've been talking with my teammate @ihorrusinko and we think implementing a design-agnostic version of botkit-mock is totally possible. With that said, our team is pretty swamped with project work. I think the best solution is for my team to setup somewhat-explicit tasks for this design on https://github.com/gratifyguy/botkit-mock and then introduce them to the botkit contributor community for feedback and development.

Any feedback/thoughts on that @colestrode @benbrown ?