Join GitHub today
Q. Why would I need Bane?
If your application communicates with any other server over a network port, your application may be susceptible to failures that happen on that server. For example, if you use a third-party web service to get data, that web service may accept your connection and never respond, it may send you unexpected data, or respond with far more information than you had anticipated. All of these conditions may cause a problem in your application if you don’t plan for these kinds of failures; see Michael Nygard’s book Release It! to learn how to design your applications to survive these failures.
How do you make sure your application won’t fail under these conditions? If you have access to the target web service, you can modify it so that it responds in unexpected ways, but this may not be possible or may take an enormous amount of effort. That’s where Bane comes in: Bane is a server that comes loaded with a bunch of bad response behaviors that you can easily stand up in place of the real web service. Start up an instance of Bane with the behavior you want to test, point your application at Bane’s appropriate port, and see how your application behaves.
Q. Is Bane intended for manual testing or automated testing?
I’ve used Bane primarily for manual exploratory tests, however Bane has a Ruby API which you can use to programmatically control Bane. For some examples of using the API, look at the examples folder in the source distribution.
Bane’s own integration tests start up an instance of Bane using the Ruby API and may be used as an example for running Bane in an automated test. If you are looking for an automated way to unit test your service integration points, you may find it easier to use test doubles that throw exceptions. For example, the Java library HttpCore from Apache throws IOExceptions, HttpExceptions, and ProtocolExceptions to indicate problems in communication; you may want to unit test how your service code handles these exceptions.
Q. Where can I get a list of all the behaviors and their configuration options?
Q. Bane sent a response and immediately hung up the connection. Can I keep the connection open and respond to several client commands?
See the ForEachLine behaviors, which read a line of input and then respond. If you need to respond to some other protocol (such as responding after reading some number of bytes), please contact me or create an issue; I’d like to hear about your use case.
Q. By default Bane only listens to connections on localhost (127.0.0.1). Is there anyway I can make Bane listen on all hosts (0.0.0.0)?
Yes. As of Bane v0.3, you can now pass an option to ask Bane to listen on all hosts. Use the `-a` or `—listen-on-all-hosts` option on the command line. For example:
bane -a 3000 NeverRespond
… will start the NeverRespond behavior on port 3000, and will accept requests on all hosts.