Delay AJAX calls if the server is slow to respond
By default our AJAX calls were 2 seconds. Then they were 5 seconds
because someone reckoned 2 seconds was putting too much load on the
system. Then we made them 10 seconds while we were having an incident.
Then we made them 20 seconds for the heaviest pages, but back to 5
seconds or 2 seconds for the rest of the pages.
This is not a good situation because:
- it slows all services down equally, no matter how much traffic they
have, or which features they have switched on
- it slows everything down by the same amount, no matter how much load
the platform is under
- the values are set based on our worst performance, until we manually
remember to switch them back
- we spend time during incidents deploying changes to slow down the
dashboard refresh time because it’s a nothing-to-lose change that
might relieve some symptoms, when we could be spending time digging
into the underlying cause
This pull request makes the Javascript smarter about how long it waits
until it makes another AJAX call. It bases the delay on how long the
server takes to respond (as a proxy for how much load the server is
under).
It’s based on the square root of the response time, so is more sensitive
to slow downs early on, and less sensitive to slow downs later on. This
helps us give a more pronounced difference in delay between an AJAX call
that is fast (for example the page for a single notification) and one
that is slow (for example a dashboard for a service with lots of
traffic).
*Some examples of what this would mean for various pages*
Page | Response time | Wait until next AJAX call
---|---|---
Check a reply to address | 130ms | 1,850ms
Brand new service dashboard | 229ms | 2,783ms
HM Passport Office dashboard | 634ms | 5,294ms
NHS Coronavirus Service dashboard | 779ms | 5,977ms
_Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms
GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
|
|
|
|
const each = require('jest-each').default;
|
|
|
|
|
|
const jestDateMock = require('jest-date-mock');
|
|
|
|
|
|
|
2019-09-02 14:27:46 +01:00
|
|
|
|
const helpers = require('./support/helpers.js');
|
|
|
|
|
|
|
|
|
|
|
|
const serviceNumber = '6658542f-0cad-491f-bec8-ab8457700ead';
|
|
|
|
|
|
const resourceURL = `/services/${serviceNumber}/notifications/email.json?status=sending%2Cdelivered%2Cfailed`;
|
|
|
|
|
|
const updateKey = 'counts';
|
|
|
|
|
|
|
|
|
|
|
|
let responseObj = {};
|
|
|
|
|
|
let jqueryAJAXReturnObj;
|
|
|
|
|
|
|
|
|
|
|
|
beforeAll(() => {
|
|
|
|
|
|
|
|
|
|
|
|
// ensure all timers go through Jest
|
|
|
|
|
|
jest.useFakeTimers();
|
|
|
|
|
|
|
|
|
|
|
|
// mock the bits of jQuery used
|
|
|
|
|
|
jest.spyOn(window.$, 'ajax');
|
|
|
|
|
|
|
|
|
|
|
|
// set up the object returned from $.ajax so it responds with whatever responseObj is set to
|
|
|
|
|
|
jqueryAJAXReturnObj = {
|
|
|
|
|
|
done: callback => {
|
Delay AJAX calls if the server is slow to respond
By default our AJAX calls were 2 seconds. Then they were 5 seconds
because someone reckoned 2 seconds was putting too much load on the
system. Then we made them 10 seconds while we were having an incident.
Then we made them 20 seconds for the heaviest pages, but back to 5
seconds or 2 seconds for the rest of the pages.
This is not a good situation because:
- it slows all services down equally, no matter how much traffic they
have, or which features they have switched on
- it slows everything down by the same amount, no matter how much load
the platform is under
- the values are set based on our worst performance, until we manually
remember to switch them back
- we spend time during incidents deploying changes to slow down the
dashboard refresh time because it’s a nothing-to-lose change that
might relieve some symptoms, when we could be spending time digging
into the underlying cause
This pull request makes the Javascript smarter about how long it waits
until it makes another AJAX call. It bases the delay on how long the
server takes to respond (as a proxy for how much load the server is
under).
It’s based on the square root of the response time, so is more sensitive
to slow downs early on, and less sensitive to slow downs later on. This
helps us give a more pronounced difference in delay between an AJAX call
that is fast (for example the page for a single notification) and one
that is slow (for example a dashboard for a service with lots of
traffic).
*Some examples of what this would mean for various pages*
Page | Response time | Wait until next AJAX call
---|---|---
Check a reply to address | 130ms | 1,850ms
Brand new service dashboard | 229ms | 2,783ms
HM Passport Office dashboard | 634ms | 5,294ms
NHS Coronavirus Service dashboard | 779ms | 5,977ms
_Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms
GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
|
|
|
|
// The server takes 1 second to respond
|
|
|
|
|
|
jestDateMock.advanceBy(1000);
|
2019-09-02 14:27:46 +01:00
|
|
|
|
callback(responseObj);
|
|
|
|
|
|
return jqueryAJAXReturnObj;
|
|
|
|
|
|
},
|
|
|
|
|
|
fail: () => {}
|
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
$.ajax.mockImplementation(() => jqueryAJAXReturnObj);
|
|
|
|
|
|
|
|
|
|
|
|
// because we're running in node, diffDOM executes as a module
|
|
|
|
|
|
// in the normal browser environment it will attach to window so we replicate that here
|
|
|
|
|
|
window.diffDOM = require('../../node_modules/diff-dom/diffDOM.js');
|
|
|
|
|
|
require('../../app/assets/javascripts/updateContent.js');
|
|
|
|
|
|
|
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
|
|
afterAll(() => {
|
|
|
|
|
|
require('./support/teardown.js');
|
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
|
|
describe('Update content', () => {
|
|
|
|
|
|
|
|
|
|
|
|
beforeEach(() => {
|
|
|
|
|
|
|
|
|
|
|
|
// store HTML in string to allow use in AJAX responses
|
|
|
|
|
|
HTMLString = `
|
|
|
|
|
|
<div data-module="update-content" data-resource="${resourceURL}" data-key="${updateKey}" aria-live="polite">
|
|
|
|
|
|
<div class="bottom-gutter ajax-block-container">
|
|
|
|
|
|
<ul role="tablist" class="pill">
|
|
|
|
|
|
<li aria-selected="true" role="tab">
|
|
|
|
|
|
<div class="pill-selected-item" tabindex="0">
|
|
|
|
|
|
<div class="big-number-smaller">
|
|
|
|
|
|
<div class="big-number-number">0</div>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<div class="pill-label">total</div>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
<li aria-selected="false" role="tab">
|
2020-02-19 13:49:29 +00:00
|
|
|
|
<a class="govuk-link govuk-link--no-visited-state" href="/services/6658542f-0cad-491f-bec8-ab8457700ead/notifications/email?status=sending">
|
2019-09-02 14:27:46 +01:00
|
|
|
|
<div class="big-number-smaller">
|
|
|
|
|
|
<div class="big-number-number">0</div>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<div class="pill-label">sending</div>
|
|
|
|
|
|
</a>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
<li aria-selected="false" role="tab">
|
2020-02-19 13:49:29 +00:00
|
|
|
|
<a class="govuk-link govuk-link--no-visited-state" href="/services/6658542f-0cad-491f-bec8-ab8457700ead/notifications/email?status=delivered">
|
2019-09-02 14:27:46 +01:00
|
|
|
|
<div class="big-number-smaller">
|
|
|
|
|
|
<div class="big-number-number">0</div>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<div class="pill-label">delivered</div>
|
|
|
|
|
|
</a>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
<li aria-selected="false" role="tab">
|
2020-02-19 13:49:29 +00:00
|
|
|
|
<a class="govuk-link govuk-link--no-visited-state" href="/services/6658542f-0cad-491f-bec8-ab8457700ead/notifications/email?status=failed">
|
2019-09-02 14:27:46 +01:00
|
|
|
|
<div class="big-number-smaller">
|
|
|
|
|
|
<div class="big-number-number">0</div>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<div class="pill-label">failed</div>
|
|
|
|
|
|
</a>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
</div>`;
|
|
|
|
|
|
|
|
|
|
|
|
document.body.innerHTML = HTMLString;
|
|
|
|
|
|
|
|
|
|
|
|
// default the response to match the existing content
|
|
|
|
|
|
responseObj[updateKey] = HTMLString;
|
|
|
|
|
|
|
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
|
|
afterEach(() => {
|
|
|
|
|
|
|
|
|
|
|
|
document.body.innerHTML = '';
|
|
|
|
|
|
|
|
|
|
|
|
// tidy up record of mocked AJAX calls
|
|
|
|
|
|
$.ajax.mockClear();
|
|
|
|
|
|
|
|
|
|
|
|
// ensure any timers set by continually starting the module are cleared
|
|
|
|
|
|
jest.clearAllTimers();
|
|
|
|
|
|
|
|
|
|
|
|
});
|
Delay AJAX calls if the server is slow to respond
By default our AJAX calls were 2 seconds. Then they were 5 seconds
because someone reckoned 2 seconds was putting too much load on the
system. Then we made them 10 seconds while we were having an incident.
Then we made them 20 seconds for the heaviest pages, but back to 5
seconds or 2 seconds for the rest of the pages.
This is not a good situation because:
- it slows all services down equally, no matter how much traffic they
have, or which features they have switched on
- it slows everything down by the same amount, no matter how much load
the platform is under
- the values are set based on our worst performance, until we manually
remember to switch them back
- we spend time during incidents deploying changes to slow down the
dashboard refresh time because it’s a nothing-to-lose change that
might relieve some symptoms, when we could be spending time digging
into the underlying cause
This pull request makes the Javascript smarter about how long it waits
until it makes another AJAX call. It bases the delay on how long the
server takes to respond (as a proxy for how much load the server is
under).
It’s based on the square root of the response time, so is more sensitive
to slow downs early on, and less sensitive to slow downs later on. This
helps us give a more pronounced difference in delay between an AJAX call
that is fast (for example the page for a single notification) and one
that is slow (for example a dashboard for a service with lots of
traffic).
*Some examples of what this would mean for various pages*
Page | Response time | Wait until next AJAX call
---|---|---
Check a reply to address | 130ms | 1,850ms
Brand new service dashboard | 229ms | 2,783ms
HM Passport Office dashboard | 634ms | 5,294ms
NHS Coronavirus Service dashboard | 779ms | 5,977ms
_Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms
GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
|
|
|
|
|
2019-09-02 14:27:46 +01:00
|
|
|
|
test("It should make requests to the URL specified in the data-resource attribute", () => {
|
|
|
|
|
|
|
|
|
|
|
|
// start the module
|
|
|
|
|
|
window.GOVUK.modules.start();
|
2020-04-16 13:21:24 +01:00
|
|
|
|
jest.advanceTimersByTime(2000);
|
2019-09-02 14:27:46 +01:00
|
|
|
|
|
|
|
|
|
|
expect($.ajax.mock.calls[0][0]).toEqual(resourceURL);
|
|
|
|
|
|
|
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
|
|
test("If the response contains no changes, the DOM should stay the same", () => {
|
|
|
|
|
|
|
|
|
|
|
|
// send the done callback a response with updates included
|
|
|
|
|
|
responseObj[updateKey] = HTMLString;
|
|
|
|
|
|
|
|
|
|
|
|
// start the module
|
|
|
|
|
|
window.GOVUK.modules.start();
|
2020-04-16 13:21:24 +01:00
|
|
|
|
jest.advanceTimersByTime(2000);
|
2019-09-02 14:27:46 +01:00
|
|
|
|
|
|
|
|
|
|
// check the right DOM node is updated
|
|
|
|
|
|
expect(document.querySelectorAll('.big-number-number')[0].textContent.trim()).toEqual("0");
|
|
|
|
|
|
|
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
|
|
test("If the response contains changes, it should update the DOM with them", () => {
|
|
|
|
|
|
|
|
|
|
|
|
// send the done callback a response with updates included
|
|
|
|
|
|
responseObj[updateKey] = HTMLString.replace(/<div class="big-number-number">0<\/div>{1}/, '<div class="big-number-number">1</div>');
|
|
|
|
|
|
|
|
|
|
|
|
// start the module
|
|
|
|
|
|
window.GOVUK.modules.start();
|
2020-04-16 13:21:24 +01:00
|
|
|
|
jest.advanceTimersByTime(2000);
|
2019-09-02 14:27:46 +01:00
|
|
|
|
|
|
|
|
|
|
// check the right DOM node is updated
|
|
|
|
|
|
expect(document.querySelectorAll('.big-number-number')[0].textContent.trim()).toEqual("1");
|
|
|
|
|
|
|
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
|
|
describe("By default", () => {
|
|
|
|
|
|
|
|
|
|
|
|
beforeEach(() => {
|
|
|
|
|
|
|
|
|
|
|
|
// start the module
|
|
|
|
|
|
window.GOVUK.modules.start();
|
|
|
|
|
|
|
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
|
|
test("It should use the GET HTTP method", () => {
|
|
|
|
|
|
|
2020-04-16 13:21:24 +01:00
|
|
|
|
jest.advanceTimersByTime(2000);
|
2019-09-02 14:27:46 +01:00
|
|
|
|
expect($.ajax.mock.calls[0][1].method).toEqual('get');
|
|
|
|
|
|
|
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
|
|
test("It shouldn't send any data as part of the requests", () => {
|
|
|
|
|
|
|
2020-04-16 13:21:24 +01:00
|
|
|
|
jest.advanceTimersByTime(2000);
|
2019-09-02 14:27:46 +01:00
|
|
|
|
expect($.ajax.mock.calls[0][1].data).toEqual({});
|
|
|
|
|
|
|
|
|
|
|
|
});
|
|
|
|
|
|
|
Delay AJAX calls if the server is slow to respond
By default our AJAX calls were 2 seconds. Then they were 5 seconds
because someone reckoned 2 seconds was putting too much load on the
system. Then we made them 10 seconds while we were having an incident.
Then we made them 20 seconds for the heaviest pages, but back to 5
seconds or 2 seconds for the rest of the pages.
This is not a good situation because:
- it slows all services down equally, no matter how much traffic they
have, or which features they have switched on
- it slows everything down by the same amount, no matter how much load
the platform is under
- the values are set based on our worst performance, until we manually
remember to switch them back
- we spend time during incidents deploying changes to slow down the
dashboard refresh time because it’s a nothing-to-lose change that
might relieve some symptoms, when we could be spending time digging
into the underlying cause
This pull request makes the Javascript smarter about how long it waits
until it makes another AJAX call. It bases the delay on how long the
server takes to respond (as a proxy for how much load the server is
under).
It’s based on the square root of the response time, so is more sensitive
to slow downs early on, and less sensitive to slow downs later on. This
helps us give a more pronounced difference in delay between an AJAX call
that is fast (for example the page for a single notification) and one
that is slow (for example a dashboard for a service with lots of
traffic).
*Some examples of what this would mean for various pages*
Page | Response time | Wait until next AJAX call
---|---|---
Check a reply to address | 130ms | 1,850ms
Brand new service dashboard | 229ms | 2,783ms
HM Passport Office dashboard | 634ms | 5,294ms
NHS Coronavirus Service dashboard | 779ms | 5,977ms
_Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms
GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
|
|
|
|
test("It should request updates with a dynamic interval", () => {
|
2019-09-02 14:27:46 +01:00
|
|
|
|
|
2020-04-16 13:21:24 +01:00
|
|
|
|
// First call doesn’t happen in the first 2000ms
|
|
|
|
|
|
jest.advanceTimersByTime(1999);
|
|
|
|
|
|
expect($.ajax).toHaveBeenCalledTimes(0);
|
|
|
|
|
|
|
|
|
|
|
|
// But it happens after 2000ms by default
|
|
|
|
|
|
jest.advanceTimersByTime(1);
|
2019-09-02 14:27:46 +01:00
|
|
|
|
expect($.ajax).toHaveBeenCalledTimes(1);
|
|
|
|
|
|
|
Delay AJAX calls if the server is slow to respond
By default our AJAX calls were 2 seconds. Then they were 5 seconds
because someone reckoned 2 seconds was putting too much load on the
system. Then we made them 10 seconds while we were having an incident.
Then we made them 20 seconds for the heaviest pages, but back to 5
seconds or 2 seconds for the rest of the pages.
This is not a good situation because:
- it slows all services down equally, no matter how much traffic they
have, or which features they have switched on
- it slows everything down by the same amount, no matter how much load
the platform is under
- the values are set based on our worst performance, until we manually
remember to switch them back
- we spend time during incidents deploying changes to slow down the
dashboard refresh time because it’s a nothing-to-lose change that
might relieve some symptoms, when we could be spending time digging
into the underlying cause
This pull request makes the Javascript smarter about how long it waits
until it makes another AJAX call. It bases the delay on how long the
server takes to respond (as a proxy for how much load the server is
under).
It’s based on the square root of the response time, so is more sensitive
to slow downs early on, and less sensitive to slow downs later on. This
helps us give a more pronounced difference in delay between an AJAX call
that is fast (for example the page for a single notification) and one
that is slow (for example a dashboard for a service with lots of
traffic).
*Some examples of what this would mean for various pages*
Page | Response time | Wait until next AJAX call
---|---|---
Check a reply to address | 130ms | 1,850ms
Brand new service dashboard | 229ms | 2,783ms
HM Passport Office dashboard | 634ms | 5,294ms
NHS Coronavirus Service dashboard | 779ms | 5,977ms
_Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms
GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
|
|
|
|
// It took the server 1000ms to respond to the first call so we
|
|
|
|
|
|
// will back off – the next call shouldn’t happen in the next 6904ms
|
|
|
|
|
|
jest.advanceTimersByTime(6904);
|
|
|
|
|
|
expect($.ajax).toHaveBeenCalledTimes(1);
|
2019-09-02 14:27:46 +01:00
|
|
|
|
|
Delay AJAX calls if the server is slow to respond
By default our AJAX calls were 2 seconds. Then they were 5 seconds
because someone reckoned 2 seconds was putting too much load on the
system. Then we made them 10 seconds while we were having an incident.
Then we made them 20 seconds for the heaviest pages, but back to 5
seconds or 2 seconds for the rest of the pages.
This is not a good situation because:
- it slows all services down equally, no matter how much traffic they
have, or which features they have switched on
- it slows everything down by the same amount, no matter how much load
the platform is under
- the values are set based on our worst performance, until we manually
remember to switch them back
- we spend time during incidents deploying changes to slow down the
dashboard refresh time because it’s a nothing-to-lose change that
might relieve some symptoms, when we could be spending time digging
into the underlying cause
This pull request makes the Javascript smarter about how long it waits
until it makes another AJAX call. It bases the delay on how long the
server takes to respond (as a proxy for how much load the server is
under).
It’s based on the square root of the response time, so is more sensitive
to slow downs early on, and less sensitive to slow downs later on. This
helps us give a more pronounced difference in delay between an AJAX call
that is fast (for example the page for a single notification) and one
that is slow (for example a dashboard for a service with lots of
traffic).
*Some examples of what this would mean for various pages*
Page | Response time | Wait until next AJAX call
---|---|---
Check a reply to address | 130ms | 1,850ms
Brand new service dashboard | 229ms | 2,783ms
HM Passport Office dashboard | 634ms | 5,294ms
NHS Coronavirus Service dashboard | 779ms | 5,977ms
_Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms
GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
|
|
|
|
// But it should happen after 6905ms
|
|
|
|
|
|
jest.advanceTimersByTime(1);
|
2019-09-02 14:27:46 +01:00
|
|
|
|
expect($.ajax).toHaveBeenCalledTimes(2);
|
|
|
|
|
|
|
|
|
|
|
|
});
|
|
|
|
|
|
|
Delay AJAX calls if the server is slow to respond
By default our AJAX calls were 2 seconds. Then they were 5 seconds
because someone reckoned 2 seconds was putting too much load on the
system. Then we made them 10 seconds while we were having an incident.
Then we made them 20 seconds for the heaviest pages, but back to 5
seconds or 2 seconds for the rest of the pages.
This is not a good situation because:
- it slows all services down equally, no matter how much traffic they
have, or which features they have switched on
- it slows everything down by the same amount, no matter how much load
the platform is under
- the values are set based on our worst performance, until we manually
remember to switch them back
- we spend time during incidents deploying changes to slow down the
dashboard refresh time because it’s a nothing-to-lose change that
might relieve some symptoms, when we could be spending time digging
into the underlying cause
This pull request makes the Javascript smarter about how long it waits
until it makes another AJAX call. It bases the delay on how long the
server takes to respond (as a proxy for how much load the server is
under).
It’s based on the square root of the response time, so is more sensitive
to slow downs early on, and less sensitive to slow downs later on. This
helps us give a more pronounced difference in delay between an AJAX call
that is fast (for example the page for a single notification) and one
that is slow (for example a dashboard for a service with lots of
traffic).
*Some examples of what this would mean for various pages*
Page | Response time | Wait until next AJAX call
---|---|---
Check a reply to address | 130ms | 1,850ms
Brand new service dashboard | 229ms | 2,783ms
HM Passport Office dashboard | 634ms | 5,294ms
NHS Coronavirus Service dashboard | 779ms | 5,977ms
_Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms
GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
|
|
|
|
each([
|
|
|
|
|
|
[1000, 0],
|
|
|
|
|
|
[1500, 100],
|
|
|
|
|
|
[4590, 500],
|
|
|
|
|
|
[6905, 1000],
|
|
|
|
|
|
[24000, 10000],
|
|
|
|
|
|
]).test('It calculates a delay of %dms if the API responds in %dms', (waitTime, responseTime) => {
|
|
|
|
|
|
expect(
|
|
|
|
|
|
window.GOVUK.Modules.UpdateContent.calculateBackoff(responseTime)
|
|
|
|
|
|
).toBe(
|
|
|
|
|
|
waitTime
|
|
|
|
|
|
);
|
|
|
|
|
|
});
|
|
|
|
|
|
|
2019-09-02 14:27:46 +01:00
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
|
|
describe("If a form is used as a source for data, referenced in the data-form attribute", () => {
|
|
|
|
|
|
|
|
|
|
|
|
beforeEach(() => {
|
|
|
|
|
|
|
|
|
|
|
|
document.body.innerHTML += `
|
|
|
|
|
|
<form method="post" id="service">
|
|
|
|
|
|
<input type="hidden" name="serviceName" value="Buckhurst surgery" />
|
|
|
|
|
|
<input type="hidden" name="serviceNumber" value="${serviceNumber}" />
|
|
|
|
|
|
</form>`;
|
|
|
|
|
|
|
|
|
|
|
|
document.querySelector('[data-module=update-content]').setAttribute('data-form', 'service');
|
|
|
|
|
|
|
|
|
|
|
|
// start the module
|
|
|
|
|
|
window.GOVUK.modules.start();
|
|
|
|
|
|
|
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
|
|
test("requests should use the same HTTP method as the form", () => {
|
|
|
|
|
|
|
2020-04-16 13:21:24 +01:00
|
|
|
|
jest.advanceTimersByTime(2000);
|
2019-09-02 14:27:46 +01:00
|
|
|
|
expect($.ajax.mock.calls[0][1].method).toEqual('post');
|
|
|
|
|
|
|
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
|
|
test("requests should use the data from the form", () => {
|
|
|
|
|
|
|
2020-04-16 13:21:24 +01:00
|
|
|
|
jest.advanceTimersByTime(2000);
|
2019-09-02 14:27:46 +01:00
|
|
|
|
expect($.ajax.mock.calls[0][1].data).toEqual(helpers.getFormDataFromPairs([
|
|
|
|
|
|
['serviceName', 'Buckhurst surgery'],
|
|
|
|
|
|
['serviceNumber', serviceNumber]
|
|
|
|
|
|
]));
|
|
|
|
|
|
|
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
|
|
});
|