Mountebank lifecycle with testing frameworks under Windows

[sro...@thoughtworks.com]

I'm curious what is the recommended strategy for managing the Mountebank lifecycle.

We have a IIS web app under test running on the same box as an instance of mb. The web app in question has the URLs we use for our service calls replaced with the appropriate imposter URLs. All is well in the world.

However, I'm wiring up the test automation now. Is the idea to spin up a copy of mb at the beginning of our test suite and kill it off at the end? Is there a request I can make to mb to get it to shut itself down, or is killing the process my only option.

The test environment is driven by jasmine unit tests under node. I'm already juggling a couple processes and would really rather not juggle some more. Is there a nice way to run up mountebank in-process with jasmine?

Thanks in advance, xoxo, lots of love, and you're all fantastic,

Scott.

[Brandon Byars]

Hi Scott,

The recommended life cycle is to spin up mb as part of your build script before the appropriate tests run and to kill the process (again in the build script) after the tests.  'mb stop' will kill the process from the command line.

mountebank itself has a grunt build script that does this.  Line 129 here is the 'mb' task: https://github.com/bbyars/mountebank/blob/master/Gruntfile.js.  It's a little more complicated than what you will need because I have to pick the distributable version of mb to run rather than the source version.  Near the end of the Gruntfile is the following task definition, which defines the lifecycle:

grunt.registerTask('test:functional', 'Run the functional tests', ['dist', 'mb:restart', 'mochaTest:functional', 'mb:stop']);

'mb restart' (which is the command line the mb:restart task translates into) just makes sure to kill any running mb process in case there's a straggler.  This is because there's a minor bug in the test:functional definition where, if a functional test fails, it does not kill mb.  I've simply been too lazy to fix that, and mb:restart is an easy workaround.

Unfortunately, there's no way to run mb in process with jasmine.

Hope that helps - holler if you need more help.

-Brandon

--
You received this message because you are subscribed to the Google Groups "mountebank-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mountebank-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Scott Robinson]

Thank you Brandon!

Yeah, the whole straggler process thing is the biggest pain for me. I'm running on shared infrastructure, so having processes lying around? That's a paddlin'.

If I get some nice tasks written around mb, is it worth giving you a pull request back to get it integrated or should I be looking at making a grunt-mountebank?

[Brandon Byars]

Yep understood - I am able to cheat in a way not everyone is.  Better grunt mb tasks would definitely be appreciated.  I like the idea of a grunt-mountebank, but I'll let you sort out what works best.

[Scott Robinson]

Sadly, I can make no promises. Mountebank is solidly in trial mode, competing against require('http').createServer ;-)

[Brandon Byars]

Understood.  Would you be willing to share the winning option and the reasons when you get to that point?  That can help just in terms of product management.

[Scott Robinson]

Absolutely! I'll leave this thread starred for that very purpose.

And feel free to hit me up in a week if I don't follow up.

[Scott Robinson]

Mountebank was dropped for my project. We now have a 100 line "stub_servers.js" sitting in our test helpers that uses node.http.

What worked:

• npm install mountebank worked, even though we didn't (and couldn't) install it in the recommended -g mode.
  
• The stubbing model. Pushing things to different ports that changed each time forced us to make our endpoint model and injection code decent.
  
• Documentation! Oh my gosh, the docs are crisp and great. Though there is a flip side to this, see below...

What didn't:

• node_modules for mountebank went too deep for Windows. On our local boxes, this wasn't an issue because our repos are checked out in a root-level, shortly named directory. But for the build servers, we didn't have that level of control. This isn't solely a mountebank issue, but it bit us there.
  
• Complexity in setting up stubs. Mountebank's resolvers syntax is perfectly comprehensive and totally difficult to explain to someone who hasn't done something like that before. Wishlist: mountebank client libraries, starting with node and working outward. Because an ad-hoc one got written immediately.
  
• Server process lifecycle. While this wasn't my preference, we ended up having to juggle our app server, selenium, our tests (protractor / jasmine), and mountebank.
  
• The docs set too high of an expectation. The limited (basically, non-functioning) ability to add an imposter via the UI was frustrating. Some devs liked the UI to see what was happening and didn't like that they had to switch back to the code to poke and pull at things. (My response to this complaint was a blank look and "no comment.")

Hope this feedback is helpful!

[Brandon Byars]

Very helpful indeed.  It reinforces a couple of items on my todo list.  I intended to write the UI for the imposters, but after realizing how much work it would be wanted some validation that it was worth it.  Same with client libraries.

Thanks for the feedback!