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.

Testing Jasmine Speed

Initial Testing

Non-Iterative Testing

Conclusion