I was told, "a single it within a describe is an order or magnitude faster than multiple its within the same describe." I thanked the individual and walked away. Then, what he said to me sank in ... and, to say I was dubious would be an understatement.
This was something I had to test ...
The code supporting this article is HERE.
Initial Testing
Initial Results:
| Type | Random Run | Result |
|---|---|---|
| Multiple IT within DESCRIBE | TRUE | 4.294s |
| Multiple IT within DESCRIBE | FALSE | 4.375s |
| Single IT within many DESCRIBES | TRUE | 8.426s |
| Single IT within many DESCRIBES | FALSE | 8.380s |
The multiple IT within DESCRIBE code looks like this ...
describe('speed testing', function() {
const maxRuns = 10000;
function multipleIt() {
it('something simple', function() {
expect(true).toEqual(true);
});
}
describe('multiple its per describe', function() {
describe('wrapper', function() {
for (let i = 0, len = maxRuns; i < len; i++) {
multipleIt();
}
});
});
});
... and the single IT within many DESCRIBES code looks like this ...
describe('speed testing', function() {
const maxRuns = 10000;
function singleIt() {
describe('single it run', function() {
it('something simple', function() {
expect(true).toEqual(true);
});
});
}
describe('single it per describe', function() {
for (let i = 0, len = maxRuns; i < len; i++) {
singleIt();
}
});
});
Then, I got to thinking that maybe the for-loop in the tests above was in some way impacting the test runs. So, I reworked the two test suites. I also added in testing that covered multiple nested DESCRIBE ...
Non-Iterative Testing
| Number of Tests | Type | Random Run | Result |
|---|---|---|---|
| 1,000 | Multiple DESCRIBE | TRUE | 5.182s |
| 1,000 | Multiple DESCRIBE | FALSE | 5.109s |
| 1,000 | Multiple IT within DESCRIBE | TRUE | 0.534s |
| 1,000 | Multiple IT within DESCRIBE | FALSE | 0.545s |
| 1,000 | Single IT within many DESCRIBES | TRUE | 0.943s |
| 1,000 | Single IT within many DESCRIBES | FALSE | 0.959s |
The deeply nested DESCRIBE code looks like this ...
describe('wrapper 1', function() {
describe('wrapper 2', function() {
describe('wrapper 3', function() {
describe('wrapper 4', function() {
describe('wrapper 5', function() {
describe('wrapper 6', function() {
describe('wrapper 7', function() {
describe('wrapper 8', function() {
describe('wrapper 9', function() {
describe('wrapper 10', function() {
it('something simple', function() {
expect(true).toEqual(true);
});
});
});
});
});
});
});
});
});
});
});
The multiple IT within DESCRIBE code looks like this ...
describe('speed testing', function() {
describe('multiple its per describe 1000', function() {
describe('wrapper', function() {
it('something simple', function() {
expect(true).toEqual(true);
});
// ... 998 ITS like the one above (or below)
it('something simple', function() {
expect(true).toEqual(true);
});
});
});
});
... and the single IT within many DESCRIBES code looks like ...
describe('speed testing', function() {
describe('single it per describe 1000', function() {
describe('single it run', function() {
it('something simple', function() {
expect(true).toEqual(true);
});
});
// ... 998 DESCRIBES like the one above (or below)
describe('single it run', function() {
it('something simple', function() {
expect(true).toEqual(true);
});
});
});
});
Conclusion
Common sense won out ...
The data here supports what common sense told me; that having multiple ITS within a single DESCRIBE is inherently faster within Jasmine than having a single IT within many DESCRIBE statements.
Additionally, the slowest of the types of tests are the deeply nested DESCRIBE.
Top comments (0)