Change Details

While porting View.js and PageGateway.js to webpack (T203100+T203817), we hit several problems porting the tests. The tests need sinon to work and adding sinon seems like a useful thing for our tests. = Acceptance criteria [] The sinon interface is available, with the same version as MediaWiki core (and pegged to that version) [] sinon is available consistently with how it made available in MediaWiki core (ie. if the tests run in Special:JavaScript/qunit/plain they run the same and pass the same as in headless mode [] The code for sinon loaded inside our headless QUnit tests is not loaded in Special:JavaScript/qunit which already has its own version of sinon [] Headless tests that reference sinon fail if sinon is not imported in the test itself Per @Krinkle > The this.sandbox interface (also known as "sinon-qunit") is a superset that I think we do not need and it would simplify the work here. To do this, each test will be responsible to use beforeEach and afterEach to create and restore the sinon instance (one line of code). Doing that explicitly I think would improve readability and portability of the tests, as well as to feel more familiar to developers, including those not accustomed to MediaWiki-QUnit's particular way (you can blame me for that!).

While porting View.js and PageGateway.js to webpack (T203100+T203817), we hit several problems porting the tests. The tests need sinon to work and adding sinon seems like a useful thing for our tests. = Acceptance criteria [x] The sinon interface is available, with the same version as MediaWiki core (and pegged to that version) [x] sinon is available consistently with how it made available in MediaWiki core (ie. if the tests run in Special:JavaScript/qunit/plain they run the same and pass the same as in headless mode [x] The code for sinon loaded inside our headless QUnit tests is not loaded in Special:JavaScript/qunit which already has its own version of sinon [x] Headless tests that reference sinon fail if sinon is not imported in the test itself Per @Krinkle > The this.sandbox interface (also known as "sinon-qunit") is a superset that I think we do not need and it would simplify the work here. To do this, each test will be responsible to use beforeEach and afterEach to create and restore the sinon instance (one line of code). Doing that explicitly I think would improve readability and portability of the tests, as well as to feel more familiar to developers, including those not accustomed to MediaWiki-QUnit's particular way (you can blame me for that!).

While porting View.js and PageGateway.js to webpack (T203100+T203817), we hit several problems porting the tests. The tests need sinon to work and adding sinon seems like a useful thing for our tests. = Acceptance criteria [x] The sinon interface is available, with the same version as MediaWiki core (and pegged to that version) [x] sinon is available consistently with how it made available in MediaWiki core (ie. if the tests run in Special:JavaScript/qunit/plain they run the same and pass the same as in headless mode [x] The code for sinon loaded inside our headless QUnit tests is not loaded in Special:JavaScript/qunit which already has its own version of sinon [x] Headless tests that reference sinon fail if sinon is not imported in the test itself Per @Krinkle > The this.sandbox interface (also known as "sinon-qunit") is a superset that I think we do not need and it would simplify the work here. To do this, each test will be responsible to use beforeEach and afterEach to create and restore the sinon instance (one line of code). Doing that explicitly I think would improve readability and portability of the tests, as well as to feel more familiar to developers, including those not accustomed to MediaWiki-QUnit's particular way (you can blame me for that!).