StubIt helps you write tests for your system, taking out the hassle of ensuring the availability of third party systems your code may depend upon.

Very often when developing systems, being it large or small systems, one needs to integrate with various third party systems. Often, this takes the form of calling services over HTTP, either real web-services or simply URL requests, ftp or other net protocols.

When writing tests, we are often forced with either:

(a) mock the access to external systems in test cases, or (b) ensure the external systems are up and running (and correctly configured) before running tests. One problem with (a) is, that mocking external systems in code quickly becomes brittle and hereby hard to maintain, not to mention often complex to write and get right. Another problem is, that the actual wire protocol talking is not tested, when the code is stubbed out inside the test case. On the upside of (a) is that nothing needs to be started for tests to run.

A problem with (b) is the complexity of having external test systems available. If those systems are stuff like big, corporate-wide service hub systems, they often change configuration, versions, availability etc. as others mock around with them from time to time. Suddenly, your build breaks because of some unrelated change somewhere else, that you did not know about. The good thing with (b) is that real integration is actually tested.

StubIt is supposed to present a kind of "middle way" solution, a bit more like real integration than (a) and at the same time, less real integration than (b).

For instance, mocking a web-service can be as simple as starting the StubIt webapp, preconfigured to answer certain requests with certain templates. The templates can be dumb and static or they can be intelligent and dynamic. The matching of requests to templates can be done in many ways, like pattern matching on URL, headers or actual content of the request.