jasmine-ajax fakes XMLHttpRequest responses, and the project says it is finished software

Finished software, and what that means for the version numbers

jasmine-ajax is a library that lets you define a set of fake responses for Ajax requests made by your application, specify per spec which response should be used, and keep track of the Ajax requests you make so you can make assertions about the results.

The Development Status section in the README is the first thing to read, and it is unusual to see stated this plainly. jasmine-ajax is finished software. There will be no further releases unless new bugs are found or fixes for existing bugs are contributed.

That statement interacts confusingly with the version numbers, so it is worth laying them out. The listed GitHub releases are v3.4.0 from 2018-05-17, v3.3.1 from 2016-12-10 and v3.3.0 from 2016-12-09. The package.json, however, declares version 5.0.0.

So the npm version and the tagged releases have diverged, which is normal for a project that keeps publishing to the registry without cutting GitHub tags. What it means for you is that npm install jasmine-ajax gives you 5.0.0, not 3.4.0, and that the recent work is not visible in the release tag history. The last push to the repository was on 2026-08-21.

The licence is MIT, with MIT.LICENSE at the root and the license field in package.json, and the homepage is jasmine.github.io.

This is worth knowing before you adopt a library that says it is done. A finished library is a good thing when it does what you need, because there is no roadmap to wait for and no API churn to plan around. It is a problem when you need a new capability, because there will not be one.

Installing it, and the browser route

There are two ways to install the library.

Through npm, install it as a dev dependency with `npm install --save-dev jasmine-ajax`, then require it inside your test suite where it is reachable through the jasmine global.

The README is specific about the browser case. Download mock-ajax.js and add it to your project. If you are using jasmine-browser-runner, be sure the location you put mock-ajax.js at is included in the helpers path in jasmine-browser.json. If you are using Jasmine standalone, make sure you add it to your spec runner.

That distinction between the two runners is the detail that catches people out. With jasmine-browser-runner the file has to be in the configured helpers path, which is a specific directory rather than any location, and with standalone it has to be in the spec runner file. A mock that loads but is not installed is the usual symptom, and it shows up as your application making a real network request during a test.

The package structure supports the browser route. The main field points at lib/mock-ajax.js, and the files array published to npm contains MIT.LICENSE, README.markdown, package.json and lib/mock-ajax.js. The build script is node scripts/buildDistribution.js, which generates that distribution file from the src/ directory, so the raw source in src/ is not what you consume.

The five parts of using it, and the shape of a fake response

The README describes using the library in Jasmine specs as five parts: defining test responses, installing the mock, triggering the ajax request code, defining the response for each request, and inspecting Ajax requests and setting expectations on them.

The worked example is a Foursquare venue search app, and the flow is worth following because it shows the intended order of operations. You define test responses, install the mock, trigger the request, define which response applies to each request, and then make assertions about what was sent.

The response definitions are plain JavaScript objects, and the README explains the reasoning behind them. After signing up for an API key and trying the endpoint with curl, you should have an idea of what API resources you are interested in and what sample responses look like. Once you do, you define simple JavaScript objects that will be used to build XMLHttpRequest objects later.

So the sample response data is a JavaScript object with a status and a responseText rather than a JSON file. The structure is small.

var TestResponses = {
  search: {
    success: {
      status: 200,
      responseText: '{"response":{"groups":[{"type":"nearby","name":"Nearby","items":[{"id":"4bb9fd9f3db7b7138dbd229a","name":"Pivotal Labs","contact":{"twitter":"pivotalboulder"},"location":{"address":"1701 Pearl St.","crossStreet":"at 17th St.","city":"Boulder","state":"CO","lat":40.019461,"lng":-105.273296,"distance":0},"categories":[{"id":"4bf58dd8d48988d124941735","name":"Office","pluralName":"Offices","icon":"https://foursquare.com/img/categories/building/default.png","parents":["Homes, Work, Others"],"primary":true}],"verified":false,"stats":{"checkinsCount":223,"usersCount":62},"hereNow":{"count":0}},{"id":"4af2eccbf964a5203ae921e3","name":"Laughing Goat Café","contact":{},"location":{"address":"1709 Pearl St.","crossStreet":"btw 16th & 17th","city":"Boulder","state":"CO","postalCode":"80302","country":"USA","lat":40.019321,"lng":-105.27311982,"distance":21},"categories":[{"id":"4bf58dd8d48988d1e0931735","name":"Coffee Shop","pluralName":"Coffee Shops","icon":"https://foursquare.com/img/categories/food/coffeeshop.png","parents":["Food"],"primary":true},{"id":"4bf58dd8d48988d1a7941735","name":"College Library","pluralName":"College Libraries","icon":"https://foursquare.com/img/categories/education/default.png","parents":["Colleges & Universities"]}],"verified":false,"stats":{"checkinsCount":1314,"usersCount":517},"hereNow":{"count":0}},{"id":"4ca777a597c8a1cdf7bc7aa5","name":"Ted\'s Montana Grill","contact":{"phone":"3034495546","formattedPhone":"(303) 449-5546","twitter":"TedMontanaGrill"},"location":{"address":"1701 Pearl St.","crossStreet":"17th and Pearl","city":"Boulder","state":"CO","postalCode":"80302","country":"USA","lat":40.019376,"lng":-105.273311,"distance":9},"categories":[{"id":"4bf58dd8d48988d1cc941735","name":"Steakhouse","pluralName":"Steakhouses","icon":"https://foursquare.com/img/categories/food/steakhouse.png","parents":["Food"],"primary":true}],"verified":true,"stats":{"checkinsCount":197,"usersCount":150},"url":"http://www.tedsmontanagrill.com/","hereNow":{"count":0}},{"id":"4d3cac5a8edf3704e894b2a5","name":"Pizzeria Locale","contact":{},"location":{"address":"1730 Pearl St","city":"Boulder","state":"CO","postalCode":"80302","country":"USA","lat":40.0193746,"lng":-105.2726744,"distance":53},"categories":[{"id":"4bf58dd8d48988d1ca941735","name":"Pizza Place","pluralName":"Pizza Places","icon":"https://foursquare.com/img/categories/food/pizza.png","parents":["Food"],"primary":true}],"verified":false,"stats":{"checkinsCount":511,"usersCount":338},"hereNow":{"count":2}},{"id":"4d012cd17c56370462a6b4f0","name":"The Pinyon","contact":{},"location":{"address":"1710 Pearl St.","city":"Boulder","state":"CO","country":"USA","lat":40.019219,"lng":-105.2730563,"distance":33},"categories":[{"id":"4bf58dd8d48988d14e941735","name":"American Restaurant","pluralName":"American Restaurants","icon":"https://foursquare.com/img/categories/food/default.png","parents":["Food"],"primary":true}],"verified":true,"stats":{"checkinsCount":163,"usersCount":98},"hereNow":{"count":1}}]}]}}'

Two things to note in that structure. The payload is a string rather than an object, because that is what an XHR response body is, so the library hands your application exactly what a real server would have sent. And the naming convention, a response name containing a status like success, is what lets a spec pick which response applies.

What it is compatible with, and what it is not

The compatibility statement is one line and it is the limit that matters most for a modern codebase. jasmine-ajax is currently compatible with any library that uses XMLHttpRequest.

That covers jQuery's ajax method, Backbone, and anything else built on XHR, which was the dominant pattern when the library was written and remains common in older codebases. It does not cover the Fetch API. A codebase whose data layer calls fetch will not be intercepted, because there is no XMLHttpRequest to replace.

That is the single most important thing to check before adopting it. If your application uses fetch, or a library that has moved to fetch, this library does nothing for you and you need a different approach.

The mechanism, implied by the compatibility statement and by the file name, is that the library replaces XMLHttpRequest with its own implementation. That is why it is compatible with any XHR-based library rather than only with the specific ones it was written against. The application code is untouched, the transport is swapped, and the fake responses you defined are what the application sees.

The second half of the value is the request tracking. Because the library keeps track of the Ajax requests your application makes, you can assert on them, which means you can check that the right URL was called, with the right parameters, in the right order. That is the part that testing a data layer actually requires, and it is why the library is more than a response stubber.

The toolchain around it

The package.json shows how the project is built and tested, and the choices are modern even though the library itself is not changing much.

The build script is node scripts/buildDistribution.js, which produces lib/mock-ajax.js from the src/ directory. The test script is jasmine-browser-runner, so the library tests itself in a real browser rather than in Node, which is the correct choice for something that replaces a browser API. The lint script covers src/**/*.js and spec/**/*.js with eslint, and there is an eslint.config.mjs at the root using the flat config format.

The dev dependencies are worth noting. jasmine-core is pinned to 7.0.0-pre.0, a pre-release, and the overrides block applies the same pin to jasmine-browser-runner so the two do not pull different versions of jasmine-core. jasmine-browser-runner is at 4.0.0. The build tooling uses ejs for templating, glob for file discovery, and eslint-plugin-compat alongside the browserslist field.

That browserslist is a deliberate compatibility contract: Safari 26 and above, Firefox 140 and above, and the last two versions of Chrome and Edge. The eslint-plugin-compat dependency enforces it, so a syntax feature or API not available in those browsers fails the lint rather than failing in a user's browser.

The repository also holds a release_notes/ directory, a RELEASE.md, a CODE_OF_CONDUCT.md, a .circleci/ directory alongside .github/, and a scripts/ directory. The contributors listed are Gregg Van Hove and JR Boyens, who wrote the original library.

Where jasmine-ajax is the wrong choice

Three cases argue against it.

The first is a Fetch-based codebase. The library is compatible with any library that uses XMLHttpRequest, so if your application calls fetch, nothing is intercepted and every test hits the network or hangs. The modern alternative is a fetch-level interception approach, either a dedicated library for stubbing fetch or the pattern of injecting a transport into your data layer so the test can supply one.

The second is a need for realistic protocol behaviour. jasmine-ajax fakes the transport, which means your application sees a response you constructed. It does not exercise status handling, redirects, CORS behaviour, progress events or the ordering guarantees of a real browser request. If the behaviour you are testing is the browser's behaviour, this is the wrong layer.

The third is a dependency you expect to grow. The README says plainly that there will be no further releases unless new bugs are found. That is a virtue for a small stable library and a liability for a team whose testing needs are moving toward fetch, streaming responses or request interception.

The alternative in the same direction is to mock at your own data layer rather than at the transport. If your application calls a wrapper module around its HTTP client, injecting a fake into that wrapper is less machinery and gives you exactly the responses your code sees, without caring whether the underlying library uses XHR or fetch. The difference in approach is that jasmine-ajax sits below your code and requires no changes to it, which is what makes it valuable for testing third-party widgets and legacy code, while a wrapper mock sits above and gives you finer control over the contract your own code depends on.

Editorial conclusion

jasmine-ajax fits a JavaScript team that wants to test code which calls an HTTP API through XMLHttpRequest and wants to assert on the request that was sent, since it replaces the transport rather than mocking the wrapper around it. It does not fit a Fetch-based codebase, because compatibility is with any library that uses XMLHttpRequest, and it will not gain new capabilities, since the README states it is finished software with no further releases unless bugs are found. Install with `npm install --save-dev jasmine-ajax`, and note that the package.json now carries version 5.0.0 against a 3.4.0 tag, so pin the version you test with rather than tracking latest blindly.

Frequently asked questions

Official sources

1. Issues
2. jasmine/jasmine-ajax on GitHub
3. Project website
4. README
5. Releases